Automated Information Systems Security Policy

Foreword

The U.S. Customs Service, Office of Information and Technology Automated Information Systems (AIS) Security Policy Manual is intended for those who use Customs AIS services and systems. Information throughout the manual supports the Customs mission by providing direction and guidance to protect AIS resources. It establishes uniform policies, responsibilities, and authorities for carrying out the Customs AIS Security Program. Security is provided for information that is collected, processed, transmitted, stored, or distributed for all other agencies utilizing Customs general support systems and major applications.

This high-level policy manual supplements the AIS security policies established by the U.S. Department of the Treasury, and is consistent with government-wide policies, standards, and procedures issued by the Office of Management and Budget, the Department of Commerce, the General Services Administration, and the Office of Personnel Management. Additional detailed and specific procedural guidelines, particular to Customs needs and requirements, will be issued in an iterative fashion, as appropriate. Prior releases of this manual (CIS HB 1400-04) are superseded.

Additional copies may be obtained by submitting Customs Form CF 262. Please include your street address, the number of publications you want, and either your Fed Ex, UPS, or RPS account number to pay for the shipping costs (publications are free) to: U.S. Customs Service National Distribution Center, PO Box 68912, Indianapolis, IN 46268. Non-Customs Federal and civil agencies, organizations, and members of the trade community may contact their Customs representative, or obtain the manual via the Internet from Customs World Wide Web (WWW) page on the National Technical Information Service (NTIS) FedWorld, at http://fedworld.gov, as available.

The U.S. Customs Service wishes to extend special thanks to the Federal Bureau of Investigation, Information Systems Security Unit, for valuable input which provided the basis for the development of this document, to the National Security Agency for their review and suggestions, and to the U.S. Department of the Treasury, Office of Information Systems Security, for their oversight and guidance.

(original signd by George J. Weise)

Commissioner

Distribution: G-25

Contents

INTRODUCTION..................................................................1-1
    1.1 PURPOSE...............................................................1-1
    1.2 REFERENCES............................................................1-1
    1.3 DEFINITIONS...........................................................1-1
    1.4 SCOPE.................................................................1-1
    1.5 BACKGROUND............................................................1-2
    1.6 INFORMATION SECURITY POLICY AND GUIDANCE HIERARCHY....................1-6

GENERAL POLICY................................................................2-1
    2.1 GENERAL POLICY STATEMENT..............................................2-1
    2.2 ROLES AND RESPONSIBILITIES............................................2-1

AIS SECURITY LIFE CYCLE.......................................................3-1
    3.1 SECURITY PLANNING.....................................................3-1
        3.1.1 Approvals.......................................................3-1
        3.1.2 AIS Security Plan...............................................3-2
        3.1.3 Disaster Recovery and Contingency Operations Planning ..........3-3
    3.2 SECURITY REQUIREMENTS ................................................3-4
        3.2.1 Policy Derived Requirements ....................................3-4
        3.2.2 Risk Management ................................................3-5
    3.3 DEVELOPMENT ..........................................................3-6
    3.4 CERTIFICATION AND ACCREDITATION ......................................3-6
        3.4.1 Certification...................................................3-7
        3.4.2 Accreditation...................................................3-8
    3.5 PROCEDURES AND PRACTICES..............................................3-10
    3.6 EDUCATION, TRAINING, AND AWARENESS....................................3-10
    3.7 SECURITY OVERSIGHT....................................................3-11

MINIMUM SECURITY REQUIREMENTS.................................................4-1
    4.1 FACILITY SECURITY.....................................................4-1
        4.1.1 Physical........................................................4-1
        4.1.2 Environmental...................................................4-2
    4.2 PERSONNEL SECURITY....................................................4-2
    4.3 AUTOMATED SECURITY....................................................4-3
        4.3.1 Minimum Security Requirements...................................4-3
        4.3.2 Security Assurances.............................................4-5
        4.3.3 Desirable Security Features.....................................4-7
    4.4 ADMINISTRATIVE SECURITY...............................................4-7
        4.4.1 Accountability and Access Control Criteria......................4-7
        4.4.2 Software and Data Security......................................4-8
        4.4.3 Technical Support and Maintenance...............................4-9
        4.4.4 Portable Computer Equipment.....................................4-10
        4.4.5 Classification and Controls.....................................4-10
        4.4.6 External Labels.................................................4-11
        4.4.7 Customs Work Performed at non-Customs Locations.................4-11
        4.4.8 Use of Non-Customs Owned AISs...................................4-12
    4.5 TELECOMMUNICATIONS SECURITY...........................................4-12
        4.5.1 Information System Standards....................................4-12
        4.5.2 Network Connections.............................................4-12
        4.5.4 Electronic Mail (E-Mail)........................................4-13
        4.5.5 Facsimile (FAX).................................................4-13
        4.5.6 PBX and Voice Mail Systems......................................4-14
        4.5.7 Communications Security (COMSEC)................................4-14

SECURITY INCIDENTS AND VIOLATIONS.............................................5-1

GLOSSARY......................................................................Glos-1

BIBLIOGRAPHY..................................................................Bib-1
    Selected Readings.........................................................Bib-5

APPENDIX A
    Abbreviations and Acronyms................................................A-1

APPENDIX B
    Good Security Practices...................................................B-1

APPENDIX C
    Controlled Access Protection (C2) Outline.................................C-1

APPENDIX D
    Security Plan Format...................................................D-1

APPENDIX E
    Computer Security Training.............................................E-1

APPENDIX F
    Security Requirements Methodology......................................F-1

APPENDIX G
    OMB Circulars..........................................................G-1
    OMB Circular No. A-123, Introduction & Comments........................G-1
    Circular No. A-123,  Revised...........................................G-7
    OMB Circular No. A-130, Appendix III,  Revised.........................G-16

INDEX......................................................................Index-1

Reader's Comment Form......................................................Comment-1

CHAPTER 1

INTRODUCTION

1.1 PURPOSE

This document establishes uniform policies, responsibilities, and authorities for implementing the U.S. Customs Service, from now on called Customs, Automated Information Systems (AIS) Security Program. It promotes the Customs mission and provides guidance to protect Customs AIS resources and assure adequate security for all agency information collected, processed, transmitted, stored, or disseminated in its general support systems and major applications.

Customs AIS security policies are consistent with government-wide policies, standards, and procedures issued by the Office of Management and Budget (OMB), the Department of Commerce, the General Services Administration and the Office of Personnel Management (OPM). At a minimum, the Customs AIS Security Program includes the set of controls established by OMB Circular A-130, Appendix III, Security of Federal Automated Information Resources, dated February 8, 1996.

1.2 REFERENCES

The Bibliography contains specific reference citations used in the AIS Security Policy Manual, and Selected Reading references which support the policies.

1.3 DEFINITIONS

Appear in the Glossary.

1.4 SCOPE

This policy manual supplements the AIS security policies established by the U.S. Treasury Department and presented in the Treasury Security Manual, TD P 71-10.

(1) Inclusions: Policy provisions apply to all Customs personnel, contractors acting for Customs, and all authorized users who access Customs AISs, networks, and support facilities. Policy provisions also apply to non-Customs organizations, or their representatives, who are granted access to Customs AIS resources, including other government agencies and members of the trade community.

(2) Exclusions: Microprocessors embedded in or dedicated to production or process control equipment (e.g., test and laboratory equipment) are not covered by these policy provisions.

(3) Point-of-contact: Direct questions concerning this policy manual to the Director, AIS Security Division, Office of Information and Technology, via the web feedback button.

1.5 BACKGROUND

Customs Mission: [USCS 96PLAN; USCS IRMPLAN]

Ensure that all goods and persons entering or exiting the United States do so in compliance with all the United States laws and regulation.

Protect the public against violations which threaten the national economy and health and safety.

Be the national resource for information on goods and persons crossing our borders.

Customs is committed to carry out its mission with increasing effectiveness and efficiency using information technology as an essential supporting element. Customs employees worldwide use AISs for all facets of Customs operations and to support law enforcement, government agencies, and the commercial trade community. These activities facilitate enforcement of United States laws, and the control and generation of significant financial revenue to the U.S. Treasury.

(1) AIS Security Program goals:

"All Federal applications require some level of protection. Certain applications, because of the sensitive information in them, however, require special management oversight and should be treated as major. Adequate security for other applications should be provided by security of the systems in which they operate." [OMB A-130,AIII]

(a) Establish and maintain adequate and effective AIS security safeguards (countermeasures) to ensure data confidentiality, integrity, and operational availability of all Customs AISs that process, store, or transmit non-sensitive, and sensitive but unclassified (SBU, from now on called "sensitive") information.

(b) The security program is designed to protect AIS processed information by:

(i) denying unauthorized AIS access;

(ii) restricting legitimate users to data or processes for which they are authorized; and

(iii) controlling access because of inadequate security design, implementation, or operation.

(c) AIS security safeguards will preserve information processing integrity, reliability and availability to ensure that the data are accurate and relevant to provide law enforcement and investigative support, help achieve Customs revenue collections, and meet commercial and administrative requirements. The application of Customs AIS security policies is evolutionary. When fully implemented, security programs will conform to an acceptable level of mandated Federal requirements.

(d) Within operational constraints, AIS security controls will allow required AIS services to be available to authorized users while denying these services to unauthorized users.

(2) Security classification:

(a) All Federal data, applications, and AISs must be afforded adequate security.

[OMB A-130,AIII]

(b) Unless otherwise designated, Customs general support systems and major applications are considered to contain sensitive information.

. (c) Classified (national security) information policy and procedures are addressed in Safeguarding Classified Information Handbook, CIS HB 1400-03.

(3) Information release:

The public release of information is controlled by statutes (Freedom of Information Act (FOIA), Privacy Act (PA), Electronic Communications Privacy Act, etc...). Regulations also control the release of such information, as do interagency agreements.

[OMB A-130; TD P 25-04; TD P 25-05]

(4) Policy application:

AIS security includes applicable security life-cycle requirements. Additional related programs are incorporated in this document by reference and should be considered when establishing and reviewing AIS security requirements. Their applicable policies and procedures may be obtained via the appropriate program managers.

(a) Office of Information and Technology (OIT)

The Office of Information and Technology is responsible for the design, development, programming, testing, implementation, and maintenance of Customs automated information systems, and oversight and management of the research and development and communications functions of the Customs Service. The Office is responsible for management of all Customs computer facilities, hardware, software, data and voice telecommunications, and related financial resources. It is responsible for identifying and evaluating new technologies for application to Customs automated systems; developing and maintaining all operational aspects of Customs computer security program; establishing requirements for computer-to-computer interfaces between Customs and various trade groups and government agencies; representing Customs on matters related to automated import processing and systems development; and implementing a viable Information Resources Management (IRM) program.

(b) Applications Development Division

The Applications Development Division is responsible for the design, development, programming, testing, implementation and maintenance of Customs automated information systems. The Division, in conjunction with the ADP Steering Committee, is responsible for approving project initiation. Specifically, this organization will be responsible for: providing system-specific support for users on existing applications during the transition to new integrated systems; change control and software release; and correcting system problems that arise after implementation. In addition, the project teams operating out of this Division are assigned full responsibility for development of new systems and major enhancements to existing systems. They are multi-functional and integrated to address both systems development efforts and new technologies.

The User Support Services Division is responsible for functions that deal directly with field users on a daily basis, including training activities supporting mainframe and distributed/PC/LAN applications, support of field equipment, including installation of PCs, LANs and peripheral equipment, data and voice communication lines and circuits; providing user assistance, including LAN administration; operation of the Customs Help Desk; and supporting all users of Customs automated systems.

(b) AIS Security Division (AISS)

(i) Develops security policies and standards.

(ii) Provides liaison activities for AIS security-related policies, issues, and products:

within Customs,

to the Department of Treasury and outside agencies,

to the trade community,

to other law enforcement agencies, and

to private organizations.

(iii) Manages security software packages.

(iv) Administers security access controls for Customs mainframe systems.

(v) Provides assistance and certification for Customs AIS users.

(vi) Coordinates the development of disaster recovery and contingency plans.

(i) Develops guidelines and standards for all developmental activities.

(ii) Performs and coordinates IRM reviews, and monitors corrective actions.

(iii) Provides security oversight.

(iv) Evaluates and plans Customs AIS resource capacity requirements.

(v) Coordinates strategic planning efforts.

(vi) Conducts analytical studies as needed in support of all OIT entities.

(vii) Provides technology assessments.

(viii) Develops the Information Systems Plan (ISP).

(ix) Plans and coordinates major procurements for AIS equipment and services.

(x) Provides Systems Development Life Cycle (SDLC) advice, assistance, and ensures compliance.

(d) Systems Operations Division (OPS)

The Systems Operations Division is responsible for managing all new and existing Customs computer facilities, hardware and software, and for managing the related financial resources. It is responsible for data base administration; systems engineering; computer operations; communications software design and implementation; and management of the Customs Data Center facility.

(e) Security Programs Division (SPD)

The Security Programs Division prescribes policy, procedures, and specifications for maintaining Customs personnel security programs.

The Security Programs Division, Security Management Branch is responsible for facility and industrial security programs.

(f) Communications Management Division (CMD)

The Office of Investigations, Communications Management Division, Communications Security Branch sets policy for handling Customs communications security (COMSEC) materials and equipment, and establishes standards and procedures for granting authorization to Customs employees for access or use of those materials and equipment. They also evaluate and approve AIS cryptography and communications security measures. [USCS 4300-09]

(g) Office of Regulations and Rulings (ORR)

The Office of Regulations and Rulings, Disclosure Law Branch, sets policy for Customs Freedom of Information Act and Privacy Act (FOIA/PA) programs.

[TD P 25-04; TD P 25-05]

(h) Office of Chief Counsel

The Office of Chief Counsel provides legal advice to all Customs Offices on Customs enforcement authorities and related subjects.

1.6 INFORMATION SECURITY POLICY AND GUIDANCE HIERARCHY

The following is for general information purposes. It is copied from Introduction to Certification and Accreditation. [NCSC-TG-029]

Security policy exists at different levels of abstraction. Federal and national-level policy is stated in public laws, Executive Orders (EO), National Security Directives (NSD), National Security Telecommunications and Information Systems Security (NSTISS) issuances, Federal Information Processing Standard Publications (FIPS PUBS), Office of Management and Budget (OMB) circulars, and other resources. Federal service and agency policies interpret Department of Defense (DoD) and national-level policies, as appropriate, and may impose additional requirements.

* TEMPEST generally applies to classified information and is not addressed in this manual. It refers control of electronic emanations and is not authorization to use classified data. TEMPEST issues should be directed to the Treasury Office of Information Systems Security.

[TD P 71-10; HB 1400-03]

Many national and Federal security policy documents exist that apply to both civil and defense agencies. Current overall security policy does not reflect an interdependent, cohesive collection of security disciplines. This proliferation of policy makes it difficult for security personnel to keep up with the changes and be aware of all the applicable policies for a given system. Rapidly changing technology also makes it difficult for policy to keep up with new security challenges caused by advances in capabilities and technology.

CHAPTER 2

GENERAL POLICY

2.1 GENERAL POLICY STATEMENT

(1) A Customs AIS is any automated information or telecommunications system owned, leased, or operated by or for Customs.

(2) Customs will implement at least the minimum security requirements as identified in this policy, to protect AIS resources and information (non-sensitive and sensitive data) processed, stored, or transmitted by Customs AISs. Based on risk management, they may apply additional safeguards to provide the most restrictive set of controls (privileges) that permit the performance of authorized tasks (principle of least-privilege). [TD P 71-10]

(3) Sensitive information in Customs AISs must be safeguarded against unauthorized disclosure, modification, access, use, destruction, or delay in service.

[USCS 1460-010]

(4) All AISs processing, storing, or transmitting sensitive information must be accredited.

[TD P 71-10]

(5) Connectivity is prohibited between Customs AISs which handle sensitive data and any other systems or networks not under Customs authority, unless formally approved by an appropriate Customs Accrediting Authority. [USCS 5500-07]

(6) All Customs AISs are for official Customs business only and users have no expectation of privacy while using these resources. [USCS 5500-07]

(7) All persons who use, manage, operate, maintain, or develop Customs AISs, applications, or data must comply with these policies.

2.2 ROLES AND RESPONSIBILITIES

Customs performs AIS Security through a variety of roles with specific responsibilities.

The general AIS Security organization is shown in Figure 2. Customs AIS Security Organization.

(1) Commissioner of Customs responsibilities:

(a) Annually certify the adequacy of Customs AIS Security Program to the Department of the Treasury.

(b) Ensure that a viable Customs AIS security education, training, and awareness program is established.

(c) Ensure that Customs AIS Security Plan documentation is developed and maintained according to Treasury and Federal standards.

(d) Designate Accrediting Authorities (AA) for sensitive Customs AISs.

(e) Designate an oversight authority for review and validation of the AIS Security Program.

(f) Delegate to Headquarters and field managers the responsibility for assigning local AIS security officers, Designated Security Officer (DSO).

(2) The ADP Steering Committee, Security Subcommittee responsibilities:

(a) Provide general oversight authority for the AIS Security Program.

(b) Conduct independent reviews of the AIS Security Program and assure compliance with Federal and Treasury policies.

(3) Assistant Commissioner, OIT, responsibilities:

(a) Ensure that an operational AIS security program is in place which provides a centrally administered security policy. The AIS Security program must comply with at least the minimum security requirements defined by Treasury and other Federal mandates, and preserve the operational flexibility necessary to Customs.

(b) Accredit sensitive Customs AIS (general support systems and major applications). This responsibility is shared with Process Owners.

(d) Establish adequate and effective management accountability and control to ensure the protection of AIS resources.

(e) Designate an AIS Security Officer to develop, implement, and enforce the AIS Security Program to comply with C2 level functional security requirements.

(f) Support AIS security audits and reviews.

(4) The Director, AIS Security Division, responsibilities:

(a) Develop and promote the Customs AIS Security program policy, including:

(i) Interpret policy relating to AIS security functions and develop unique guidance, as needed.

(ii) Assist with policy compliance efforts by providing explanation or clarification of AIS security-related questions on issues that may impact Customs mission.

(iii) Ensure security administration for sensitive AIS, including general support systems and major applications .

(b) Coordinate the Designated Security Officers (DSOs) for sensitive Customs AISs, and provide them guidance and assistance in carrying out their functions.

(c) Review and authorize acquisitions, in coordination with the DSOs, and certify that the acquisition specifications include appropriate AIS security requirements for:

(i) AIS installation facility operations, equipment, or applications.

(ii) Acquisition of AIS hardware, software, and/or related services.

(d) Provide direction and guidance to system developers in defining and approving software development security requirements.

(e) Ensure that accreditation packages are prepared for sensitive Customs AISs and applications.

(i) Provide guidance on the scope and contents of security plans:

Review security plans prepared by or for the DSOs.

Prepare statements of residual risk and compliance summary, to complete each accreditation package.

Submit the accreditation package to the appropriate authorities.

(ii) Act as a liaison for AIS security issues to the Information Resources Management (IRM) and Security Programs Division (SPD) managers.

(f) Maintain a current status on all required accreditation documentation.

(g) Establish and maintain a Risk Management program, including risk assessments, for sensitive Customs AIS resources, including:

(i) AIS facilities.

(ii) General support AISs.

(iii) Major applications.

(h) Act as the liaison for AIS security matters to the Department of the Treasury.

(i) Report computer security incidents and violations to the OIT Assistant Commissioner (AC), Process Owners (PO), and Office of Internal Affairs (IA), as appropriate.

(j) Coordinate Customs AIS Virus Prevention program, including, recommending virus prevention solutions, providing guidance in defining the requirements, and selecting the approach.

(k) Establish standards and provide guidance for the preparation of AIS Disaster Recovery and Contingency Operations plans including, conducting of agency-wide analyses, and establishing and verifying strategies for business recovery and alternate processing. This includes coordinating the development of viable Disaster Recovery and Contingency Operations plans for Customs AIS facilities.

(l) Establish standards and provide guidance for preparing End-User AIS Contingency plans.

(m) Ensure that all interactive users of Customs AIS meet at least the minimum standards of eligibility for access. [USCS 1460-010]

(n) Conduct AIS security compliance review and oversight activities.

(o) Support areas or issues requiring AIS security-related research and development effort.

(p) Support AIS security audits and reviews, providing assistance as appropriate.

(5) IRM manager responsibilities:

(a) Ensure security-related quality assurance throughout the software development life-cycle.

(b) Coordinate with AIS Security for review of the SDLC documents and activities to incorporate security into developed products. [TD P 84-01]

(6) Process Owner (identified in the Major Application Security Plan) responsibilities:

[USCS PPP]

(a) Accredit assigned Customs AIS Process (responsibility shared with the Assistant Commissioner, OIT).``

(b) Establish user requirements and controls that conform to Customs System Development Life Cycle (SDLC) Handbook. [USCS 5500-04]

(d) Designate or ensure that information sensitivity levels are assigned for the information processed, stored, or transmitted by the Customs AIS Process.

(e) Coordinate with the Customs Office of Regulations and Rulings, Disclosure Law Branch, to publish a "System of Records" in the Federal Register for any Customs Process that contains Privacy Act data, as appropriate. [TD P 25-04]

(f) Ensure that user access requirements and controls are defined for the Customs AIS Process.

(g) Delegate user access request authorization.

(h) Assist with AIS security audits and reviews, as appropriate.

(7) Application Development Manager responsibilities:

Application development managers (both OIT and development organizations external to OIT) have data ownership responsibilities for application-related information processed, stored, created, manipulated or transmitted by and/or for the application, unless data ownership is otherwise designated by agreements, functions, and/or assignments.

(a) Ensure that locally developed AIS products comply with C2 level functional security requirements.

(b) Ensure that at least the minimum security requirements mandated by law, statute, or regulation are incorporated into Customs AIS Process applications.

(d) Prepare documentation for application certification and accreditation packages.

(e) Assist with AIS security audits and reviews, as appropriate.

(8) AIS Owner responsibilities:

(a) Ownership responsibilities for sensitive Customs AISs are assigned to the Office of Information and Technology, unless otherwise identified.

(b) Assist with AIS security audits and reviews, as appropriate.

(9) AIS Security Administrator responsibilities:

(a) Act as the primary point-of-contact for AIS security issues.

(b) Identify security threats and establish safeguards (countermeasures) to protect Customs AIS resources.

(d) Ensure that all personnel receive appropriate AIS security training.

(e) Administer the Computer Security Incident Reporting Capability (CSIRC) program including establishing reporting criteria, and coordinating with the Office of Internal Affairs (IA), as appropriate.

(f) Report to the AIS Security Officer any security incidents, such as attempts to gain unauthorized access to information, virus infections, or other events affecting AIS security, including damage assessments and actions taken to prevent future incidents, as appropriate.

(g) Ensure that viable End-User AIS Contingency Plans are developed to assure continued operations of essential AIS functions should an emergency occur.

(h) Coordinate local AIS Security Administrators.

(i) Advise Customs management on implementing provisions of this policy and applicable guidelines.

(j) Ensure all AIS operations are conducted as authorized in the accreditation, or that certification package modifications are prepared to accommodate the variances.

(k) Assist with AIS security audits and reviews, as appropriate.

(10) A Designated Security Officer (DSO) must be assigned for each sensitive AIS, including general support systems and major applications.

Designated Security Officer: The Customs person responsible to the AA for ensuring that security is provided for and implemented throughout the life-cycle of an AIS (from concept development through design, development, operations, maintenance, and disposal phases).

The DSO responsibilities:

(a) Ensure that appropriate security features are implemented in new sensitive AISs and that they meet at least the minimum security requirements defined in this policy.

Review and authorize acquisitions, in coordination with the AIS Security Officer, and certify that appropriate AIS security is included in the specifications for the operation of an AIS installation facility, equipment, or application, and for acquisition of AIS hardware, software, or related services.

(b) Prepare site certification packages in preparation for accreditation.

Certification-related activities include:

(i) Conduct design reviews, security tests, and certify the results when security-relevant changes (hardware, software, firmware, etc.) are made, to ensure that the accreditation status is not affected.

(ii) Identify and recommend AIS security improvements to management.

(iii) Ensure that configuration management (CM) is used and maintained to protect the AIS security-related features.

(c) Prepare, or oversee the preparation of, AIS security plans, and maintain related documentation for each AIS under their purview.

(d) Ensure the distribution of end-user security procedures tailored for administrators, and operators of sensitive AISs; advising users of the security features and procedures used on the AISs. [USCS 5500-04]

(e) Coordinate with the appropriate DSOs of other AISs, process owners, application development managers, and the Customs AIS Security Officer to ensure that planning adequately addresses the AIS security requirements.

(f) Establish, in coordination with AIS Security Administration, access control criteria and administrative procedures consistent with Customs policy, by which only authorized persons gain access to the AIS.

(g) Provide support for audit trail reviews and related discrepancy investigations.

(h) Report immediately to AIS Security Administration, any security incident, such as attempts to gain unauthorized access to information, virus infections, or other events or conditions which may affect AIS security accreditation.

(i) Conduct periodic security reviews of AIS facilities under their purview to assure safeguards are commensurate with the AIS information being stored, processed or transmitted.

(j) Assist with AIS security audits and reviews, as appropriate.

(11) Local AIS Security Administrator responsibilities:

(a) Request and/or grant user access to AIS based on management authorization.

(b) Remove or modify user access based on authorized requests of management, process owners, and/or administrative processes.

(c) Conduct authorized reviews of the user access to assure timely detection of suspicious, inappropriate, or unauthorized activity.

(d) Report to DSO or AIS Security Administration, any security incidents or other events affecting AIS security (e.g., virus infections, attempts to gain unauthorized access to information, suspicious, inappropriate, or unauthorized activity, etc.).

(e) Assist with AIS security audits and reviews, as appropriate.

(f) Support compliance of C2 level functional security requirements for locally developed sensitive AIS products, as appropriate.

(12) Facility manager (or functional equivalent) responsibilities:

(a) Ensure that a physical inventory is maintained (usually by the local property officer) of all AIS resources within their area of responsibility.

(b) Ensure the physical security and accreditation of the sensitive AIS facility (site).

Included in these responsibilities are AIS-related safety and security activities (e.g., Occupant Emergency Plan, Physical Security Plan, etc.).

(d) Assist with AIS security audits and reviews, as appropriate.

(13) Manager and Supervisor responsibilities:

(a) Ensure that sensitive AIS data and resources within their area of responsibility are properly protected by appropriate security safeguards.

(b) Ensure that subordinates have access only to those AIS applications and data necessary to perform authorized tasks (principle of least-privilege).

(c) Report to the appropriate Security Administrator any changes to employee access requirements. Also coordinate with appropriate management when employee or management transfers occur which might affect AIS access.

(d) Review employee AIS access activity to ensure compliance to AIS security requirements and provide timely detection of suspicious, inappropriate, or unauthorized activity.

(e) Ensure that a DSO is identified for each sensitive AIS (or group of facilities designated as a sensitive AIS) used by employees under their management authority, as warranted.

(f) Report AIS security-related changes in their own job status to the responsible Security Administrator.

(g) Ensure that proposed acquisitions of sensitive AIS-related hardware, software, communications, applications, and equipment satisfy AIS security requirements and receive DSO concurrence prior to acquisition.

(h) Ensure that sensitive AIS products developed under their management authority comply with C2 level functional security requirements.

(i) Ensure that employees under their management authority receive AIS security training relevant to their assignments, as required by laws, regulations, MOUs, or other agreements.

(j) Attend AIS security training as required by laws, regulations, MOUs, or other agreements.

(k) Assist with AIS security audits and reviews, as appropriate.

(14) User responsibilities:

(a) Protect access IDs, authentication codes (e.g., passwords, personal identification numbers [PIN], encryption codes, etc.) from improper disclosure.

(b) Access only authorized AIS applications and data necessary to perform approved responsibilities.

Due to technical capability of some AIS, access might exceed authority. Access capability however, does not equate to authority (e.g., casual browsing of data is not permitted).

It is a violation of law for users to access U.S. Government AIS data in excess of their authorization. [18 USC 1030]

(c) Notify supervisor and AIS Security Administrator when AIS access or authority is no longer required for their authorized tasks.

(d) Apply the security controls required by AIS security policies and standards.

(e) Comply with the provisions in the Customs AIS Security Policy manual.

(f) Attend AIS security training as required by laws, regulations, MOUs, or other agreements.

(g) Provide assistance with AIS security audits and reviews as required by laws, regulations, MOUs, or other agreements, as appropriate.

(15) External agency user responsibilities:

(a) Comply with U.S. Government AIS-related laws and regulations.

(b) Comply with inter-agency MOU (Memorandum of Understanding) or other formal agreements between themselves and Customs.

External agencies must designate AIS Security Coordinators. The head of the external agency, or delegate (as identified in writing), is responsible for ensuring that employees and contractors under their authority observe Customs AIS Security Policy as identified in this manual.

(c) Protect access IDs, authentication codes (e.g., passwords, personal identification numbers [PIN], encryption codes, etc.) from improper disclosure.

(d) Access only authorized AIS applications and data necessary to perform approved activities.

Due to the technical capability of some AIS, access might exceed authority. Access capability however, does not equate to authority (e.g., casual browsing of data is not permitted).

It is a violation of law for users to access U.S. Government AIS data in excess of their authorization. [18 USC 1030]

(e) Notify Customs AIS Security Administrator when AIS access or authority is no longer required for approved tasks.

(f) Use the security controls required by AIS security policies and standards.

(g) Comply with the provisions in the Customs AIS Security Policy manual.

(h) Attend AIS security training as required by laws, regulations, MOUs, or other agreements.

(i) Provide assistance with AIS security audits and reviews as required by laws, regulations, MOUs, or other agreements, as appropriate.

(16) Trade community user responsibilities:

(a) Comply with U.S. Government AIS-related laws and regulations;

(b) Comply with any formal agreements governing access to Customs AIS resources.

Trade community user access to Customs AIS resources must be approved by the appropriate Customs Accrediting Authorities and formally documented.

AIS access will be restricted to authorized data and processes. Due to the technical capability of some AIS however, access might exceed authority. Access capability does not equate to authority (e.g., casual browsing of data is not permitted).

It is a violation of law for users to access U.S. Government AIS data in excess of their authorization. [18 USC 1030]

(d) Protect access IDs, authentication codes (e.g., passwords, personal identification numbers [PIN], encryption codes, etc.) from improper disclosure.

(e) Notify Customs AIS Security Administrator when AIS access or authority is no longer required for approved tasks.

(f) Use the security controls required by Customs AIS security policies and standards.

(g) Comply with the provisions in the Customs AIS Security Policy manual.

(h) Attend AIS security training as required by laws, regulations, MOUs, or other agreements.

(i) Support Customs AIS security audits and reviews as required by laws, regulations, MOUs, or other agreements.

CHAPTER 3

AIS SECURITY LIFE CYCLE

This section documents activities for acquisition and development of AIS and related applications. It provides guidance to ensure that sensitive AISs and applications are developed, acquired, and documented according to Customs policy.

Topics include:

Security Planning. Security planning activities are the responsibility of the appropriate Customs Process Owner, AIS owner, Applications Developer, DSO, and AIS Security Officer. These activities pertain to the development or acquisition of new Customs AISs and applications, or changes to existing ones.

Certification and Accreditation. Certification and accreditation activities are the responsibility of the appropriate Accrediting Authorities (AAs), DSO, and the AIS Security Officer.

Security Education, Training, and Awareness. These activities are ongoing and apply to all personnel who manage, use, or operate Customs AISs, whether or not they are Customs employees.

Security Oversight. The AIS Security Officer conducts policy-related security oversight activities for ongoing day-to-day operations. The ADP Steering Committee, Security Subcommittee, is designated as the oversight authority for Customs AIS Security Program.

3.1 SECURITY PLANNING

Security planning activities support the accreditation of all sensitive Customs AISs, including general support systems and major applications. This section discusses the processes for AIS security planning, risk management, disaster recovery, contingency operations, and the documentation required to achieve certification and accreditation.

Prior to the development or acquisition of sensitive AISs and applications, the AIS Security Officer must be consulted to establish the scope of the security-related activities and necessary documentation.

3.1.1 Approvals

The security planning process requires the DSO to seek approvals at several steps during system planning activities.

(1) To the extent feasible, security requirements must be defined prior to the start of AIS development, be approved by the DSO and AIS Security Officer, and included as part of the acquisition process.

(2) Prior to the start of AIS development, system designs must include security reviews and be approved by the AIS Security Officer.

(3) Security test plans and security testing results must be approved by the AIS Security Officer.

(4) Prior to accreditation, AIS security planning documentation must be approved by AIS Security Administration.

3.1.2 AIS Security Plan

The objective of security planning is to improve the protection of AIS resources and information.

(1) Information owners (those managers most directly affected by and interested in the information or processing capabilities), must demonstrate how they are planning to protect information and processing capabilities from loss, misuse, unauthorized access, modification, unavailability, or undetected security-related activities.

(2) The AIS Security Officer will define the scope and format for Customs AIS security plans to ensure a standardized approach that provides sufficient information to assess the security posture and complies with applicable regulations.

(3) Each sensitive Customs AIS requires a security plan to document its security requirements, from development or acquisition, through implementation and operation, to disposal. The assigned DSO will prepare and maintain the system security plan.

(a) When an existing non-sensitive AIS is changed to a sensitive Customs AIS, an appropriate AIS Security Plan must be prepared.

(b) AIS Security Officer will determine the final boundaries for AIS networks.

(c) The DSOs will clearly define the boundaries of non-networked sensitive AISs under their purview and are responsible for ensuring that the AISs are operated according to the approved AIS security plan.

(4) An AIS security plan will include at least the following: (See also: Appendix D)

(a) Risk management actions pertaining to the AIS. (See also: Section 3.2.2)

(b) A Certification statement that reflects the results of security features tests and implementation schedules applicable to the AIS. (See also: Section 3.4)

(i) emergency response plan,

(ii) back-up operations plan, and

(iii) postdisaster recovery plan.

(d) Security procedures and practices for users and operators of AISs. (See also: Section 3.5)

(5) A single (generic) security plan can cover multiple AISs in some situations. Such plans must consider ownership responsibilities, administrative burdens, technical complexity, and be cost-effective.

(a) A single (generic) AIS security plan can include multiple comparable AISs in similar and associated operating environments. If additional security measures for a particular operating environment are required, they can be added as supplemental to the primary security plan, rather then create a new plan. The plan must show how the changes are associated and maintain the plan integrity.

(b) A single (generic) AIS security plan can cover related AIS resources that perform similar and/or associated functions and are physically and logically located in the same general area. The plan might Include Local Area Networks (LANs), hosts with terminals, groups of stand-alone personal computers, workstations, and other related office automation systems.

(c) A single (generic) AIS security plan can cover related AIS resources that perform similar and/or associated functions in support of a common mission, but might be at unspecified or physically and/or logically diverse locations. Such a plan must consider the diversity of conditions that might be encountered and ensure that adequate and appropriate levels of security are provided. The plan might include personal computers, workstations, and other related AIS equipment over Wide Area Networks (WANs), Local Area Networks (LANs), and/or other communications networks or mediums.

3.1.3 Disaster Recovery and Contingency Operations Planning

(1) Each essential (mission-critical) sensitive Customs AIS, including general support systems and major applications, or grouping of like systems, shall have a viable and logical Disaster Recovery and Contingency Operations Plan. Plans shall be well-written, routinely reviewed, tested, and updated to provide for reasonable continuity of AIS support if normal operations are interrupted. This enables rapid restoration of vital operations and resources, and reduces downtime. [OMB A-130,AIII]

(2) Disaster Recovery and Contingency Operations planning elements must include, at least the following:

(a) Emergency response procedures appropriate to government laws, regulations, and directives, civil disorder, fire, flood, natural disaster, bomb threat, or other incidents or activity where lives, property, or the capability to perform essential functions are threatened or seriously impacted.

(b) Back-up operations plans, procedures, and responsibilities to ensure that essential (mission-critical) operations will continue if normal processing or data communications are interrupted for an unacceptable period. The minimally acceptable level of degraded operation of the essential (mission-critical) systems or functions must be identified and ranked so that plan priorities are accomplished. This must include appropriate provisions for storage, maintenance, and retrieval of essential back-up and operational support data.

(c) Post-disaster recovery procedures and responsibilities to facilitate the rapid restoration of normal operations at a primary site, or if necessary at an alternate facility, following destruction, major damage, or other significant interruptions of the primary site.

(3) The AIS Security Officer is responsible for ensuring the development of AIS Disaster Recovery and Contingency Operations Plans for general support systems and major applications, and for defining the testing requirements that the DSOs will carry out.

(a) The AIS Disaster Recovery and Contingency Operations Plans shall provide for viable and reasonable continuity of essential AIS capabilities if normal operations are interrupted.

(b) The AIS Security Officer provides guidance for the formulation of these plans. The plans must address the business continuity requirements for interfacing with applications and be supported by application contingency plans.

(c) AIS application contingency planning activities are conducted in concert with facility disaster recovery planning and/or end-user contingency planning, when such plans exist.

(d) Facility disaster recovery plans address physical security, the protection of general AIS support, and help ensure the availability of critical assets (resources) to facilitate the continuity of operations during an emergency.

(4) The DSO will develop and maintain a current viable AIS Disaster Recovery and Contingency Operations Plan for each sensitive and/or mission-critical AIS (general support system, microcomputers, etc.). The plan will provide reasonable assurance that critical data processing support can be continued, or quickly resumed, if normal operations are interrupted.

(a) Depending on the results of the criticality assessment (business impact analysis), the DSO may determine that an AIS is not sufficiently critical to the agency or user community to warrant a Disaster Recovery and Contingency Operations Plan. In this event the DSO will provide a Continuity of Operations Statement to that effect, subject to the approval of the Accrediting Authorities.

(b) End-User AIS Contingency Plans shall be developed, reviewed, and updated at least every three years, or whenever major processing environment changes occur (e.g., physical site, hardware, software, operating systems, etc.).

(5) All plans must be operationally tested at a frequency commensurate with the risk and importance of loss or harm that could result from disruption of AIS support.

3.2 SECURITY REQUIREMENTS

3.2.1 Policy Derived Requirements

Security requirements must be risk management based and result from an analysis of policy as applied to data and augmented by a risk analysis. These requirements must be compared to an AIS security features cost-benefit analysis, not against the minimum requirements. Appendix F discusses policy methodology.

3.2.1.1 Global Security Policy

The security policy of Customs is to operate its AISs in compliance with existing Federal and national-level policy as stated in public laws (PL), Executive Orders (EO), Federal Information Processing Standard Publications (FIPS PUBS), Office of Management and Budget (OMB) circulars and bulletins, Treasury Directives (TD), and Customs Directives (CD); to protect the data and information in the AISs; and to effectively support the Customs mission.

3.2.1.2 Cost-Effective Security

Federal regulations and Treasury directives require that (i) resources are used consistent with the agency mission; (ii) programs and resources are protected from waste fraud and mismanagement; and (iii) the best available and most cost-effective products are used in the design and implementation of AIS security protection. The selection of security products must consider the costs of managing and administering such products. Meeting these requirements, and the continually increasing demands for protection of information, requires consideration of products which are compatible with existing and anticipated AIS hardware and software configurations. [OMB A123; TD P 71-10]

3.2.2 Risk Management

(1) Risk management is the total process of identifying, controlling, and eliminating or reducing risks that may affect AIS resources. It includes: risk analysis (identify and analyze the risks); a determination of the appropriate levels of resources necessary to protect the AIS; a management decision to implement selected AIS security safeguards based on the risk analysis, including accepting residual risk, if necessary; and effectiveness reviews.

(2) Risks are derived from the analysis of threats and vulnerabilities. A formal risk analysis requires determining relativity among risks and assessing associated damage or loss potentials. This relationship forms the basis for selecting effective safeguards. Before starting the risk analysis process, the AIS Security Officer should be consulted for guidance on the scope of the analysis and the recommended approach. In the absence of specific directions, refer to the Treasury Risk Assessment Guideline. [TD P 85-03]

(a) A risk analysis will be conducted or sponsored by the AIS Security Officer for each Customs general support AIS (mainframe or network) facility for the following conditions.

(i) Whenever a new or substantially modified AIS facility design is approved.

(ii) Before design specifications for new general support AISs and their supporting installations are approved.

(iii) Whenever a significant change occurs to the general support AIS (e.g., adding a LAN; changing from batch to on-line processing; adding dial-up capability, etc.). The criteria for defining significant changes will be commensurate with the sensitivity of the data processed by the general support AIS.

(iv) At periodic intervals established by the AIS Security Officer commensurate with the sensitivity of the data processed, but not to exceed every three years, if no risk analysis is performed during that period.

(b) The DSO will coordinate or conduct a risk analysis which focuses on the automated (technical) and administrative security control techniques associated specifically with the AIS or process under review. This includes the interface between the operating systems and the applications, and/or the communications environment and the applications, and the threats inherent in processing in a specific environment. Facility (physical) risk analysis must be considered when defining and approving security specifications for the major applications or network systems.

(3) Responsibility for carrying out the recommendations of a risk analysis rests with the manager of the AIS facility under review, or the application developer, as appropriate. Response to the recommended safeguards includes implementation schedules, or rationale for non-implementation. They must evaluate the recommendations and determine whether to carry them out based on technical and operational feasibility, and costs. Customs Accreditation Authorities (AAs) will consider the effects of the reviewer's actions in making accreditation decisions.

3.3 DEVELOPMENT

(1) The Customs System Development Life Cycle (SDLC) methodology described in the SDLC handbook applies to all systems and applications (mainframe, networked, or stand-alone), developed by or for Customs and used by Customs employees, contract personnel, other government agencies, and persons or companies using Customs resources, whether or not under direct control of the Office of Information and Technology (OIT). It incorporates a standards-based approach to systems development and AIS development policies.

(2) The SDLC handbook is required reading for all persons new to the Customs automation environment and incorporates Government and industry development standards applicable to Customs. It describes the minimum requirements that Customs applications must meet to comply with existing standards and directives throughout their projected life-cycles and facilitates a step-by-step process to deliver accurate, effective and efficient AISs to the users. [USCS 5500-4]

3.4 CERTIFICATION AND ACCREDITATION

Certification and accreditation, although related, are not the same processes nor do they have the same objectives. Certification is a short term activity that is repeated after any significant AIS-related change and is a prerequisite for accreditation. Accreditation is a long-term authorization, up to three years, for an AIS to operate based on the facts, plans, and schedules developed during certification.

(1) Each Customs general support AIS and major application is considered to contain or process sensitive information and must be certified and accredited.

(2) All other Customs AISs and applications which contain or process sensitive information and must be certified and accredited, as appropriate.

3.4.1 Certification

Certification is the comprehensive testing and evaluation of the technical and nontechnical AIS security features, and other safeguards used in support of the accreditation process. It establishes the extent to which a particular AIS design and implementation meet a specified set of security requirements. Certification primarily addresses software and hardware security safeguards, but also considers procedural, physical, and personnel security measures employed to enforce AIS security policy.

(1) Software Certification

(a) In-house developed software. Design reviews and systems tests will be performed, and a certification of the results recorded, for newly developed software, and for existing software when significant modifications are made.

(b) Government-Off-The-Shelf Software (GOTS). Government developed software will be examined to assure that the software does not contain features which might be detrimental to Customs AIS security. Software design reviews and systems tests will be performed, and a certification of the results recorded when significant modifications are made to GOTS software.

(c) Commercial-Off-The-Shelf Software (COTS). Commercially procured software will be examined to assure that the software does not contain features which might be detrimental to AIS security. Security-related software will be examined to assure that the security features function as specified.

(2) The DSO will oversee or conduct AIS certification tests. Individuals who conduct the certification testing will be independent of the AIS developers, if resources are available. The testing process and results will be documented in a format that ensures that the tests can be repeated and achieve the results reflected in the certification report, if required.

(3) AIS security safeguards must be modified to correct any deficiencies found during certification testing, as appropriate.

(4) Certification testing will vary with the AIS security mode of operation.

(a) Dedicated security mode does not require extensive certification efforts as users and data are not required to be separated with technical security measures. Certification focuses on the physical, procedural, and personnel security measures to ensure that all users have the appropriate access approval and need-to-know for all Customs data on the AIS. (Example: a standalone personal computer).

(b) System-high security mode requires that hardware and software security features reliably segregate users from data for which they do not have a need-to-know, in addition to the requirements of Dedicated security mode. (Example: a general support AIS).

(c) Compartmented and multilevel security modes are used for classified AISs and are not addressed in the manual. (Reference: CIS HB 1400-03).

(5) The AIS Security Officer will provide guidance on conducting certification testing.

3.4.2 Accreditation

"Any significant modification made to an SBU AIS or network should be reviewed to determine the impact on security."

"Modified systems/networks will be reaccredited by appropriate officials as outlined in TD P 71-10, Sect. 7.A in light of the results of the security review." [TD P 71-10]

(1) Accreditation is the official management authorization to operate an AIS based on the following criteria.

(a) The particular security mode of operation.

(b) The defined set of threats, with related vulnerabilities and prescribed safeguards.

(d) The stated operational concept.

(e) The stated interconnection to other AISs.

(f) The operational necessity.

(g) An acceptable level of risk for which the Accrediting Authorities have formally assumed responsibility.

(2) The Accrediting Authorities (AA) officially declare that a certified AIS will adequately protect related information, will operate in one of the following security modes, and accept security responsibilities for the AIS operation.

The AIS security mode of operation is based on data sensitivity, access approval, and need-to-know of the AIS users. Available or proposed AIS security features do not determine the security mode.

Applicable Security Modes of operations are:

(a) Dedicated security mode. (See also: Certification. Section 3.4.1.(4)(a).

(b) System-high security mode. (See also: Certification. Section 3.4.1.(4)(b).

(3) All sensitive AISs, including general support systems and major applications, must be submitted for and be accredited expeditiously.

(4) The AIS security plan documentation, discussed in Section 3.1, will be submitted by the DSO to the AIS Security Officer for review. The AIS Security Officer will develop a summary of compliance to include security requirements and a statement of residual risk.

(5) Prior to accreditation, Customs Information Resources Management (IRM) and Security Programs Division (SPD) representatives will review security plan documentation, for sensitive AIS, including the summary of compliance and statement of residual risk.

(6) The appropriate Customs AAs will make the accreditation decision based on the summary of compliance, a statement of residual risk, and an approved AIS security plan. The accreditation process results in a decision that the AIS is:

(a) accredited to operate, or

(b) given interim operating approval for a specific time pending satisfactory completion of specified requirements, or

(7) Every sensitive AIS covered by this policy must be reaccredited at least every three years. The accreditation status and supporting documentation will be reviewed and revised for the following conditions or events, as appropriate.

(a) A significant change occurs in the hardware, software, or data communications configuration that impacts the AIS security safeguards defined in the original accreditation package. A significant change is one whose impact is such that it needs to be brought to the attention of the AAs.

(b) The sensitivity level of the information being processed is significantly changed.

(d) AIS facility or remote terminal area changes occur, including relocations or structural modifications, which may affect AIS security.

Whenever a major office relocation occurs (e.g., moves to a new building), the AIS Security Officer should conduct an AIS compliance review to decide whether the change in physical location impacts the AIS security posture. The results of the security review should be retained as part of Customs AIS security documentation.

(e) An AIS security-related event occurs that appears to invalidate the accreditation.

(8) The accreditation package revision and review process will include at least the following activities and information.

(a) The same steps required for the original accreditation package will be completed. Portions of the package which configuration management shows to still be valid, need not be redone.

(b) The IRM and SPD representatives will review and approve the AIS security plan, summary of compliance, and statement of residual risk, as appropriate.

(9) The AIS Security Officer will maintain a record system containing the status of the documents in the Customs AIS accreditation packages.

(10) The AAs are the only ones authorized to exempt an operation from the security requirements specified in the accreditation statement. This exemption must be formally documented in a written waiver and retained with the original accreditation package.

3.5 PROCEDURES AND PRACTICES

This policy manual does not contain AIS security-related procedures and practices. They are presented separately and provided to Customs AIS users, administrators, and operators, as appropriate. Procedures and practices explain specific AIS security mechanism operations so that users, administrators, and operators may consistently and effectively protect Customs information. Such information should also be addressed during training, when applicable. ( See also: Section 1.5.1)

3.6 EDUCATION, TRAINING, AND AWARENESS

"The Computer Security Act requires Federal agencies to provide for the mandatory periodic training in computer security awareness and accepted computer security practice of all employees who are involved with the management, use, or operation of a Federal computer system within or under the supervision of the Federal agency. This includes contractors as well as employees of the agency."

"Training is particularly important in view of the changing nature of information resources management. Decentralization of information technology has placed the management of automated information and information technology directly in the hands of nearly all agency personnel rather than in the hands of a few employees at centralized facilities."

"The OMB Circular A-130, Appendix III enforces such mandatory training by requiring its completion prior to granting access to the system." [OMB A-130,AIII]

(1) The Director, AIS Security Division, shall ensure that a Customs AIS Security Education, Training, and Awareness Program is established.

(2) Training may be presented in stages, for example, as more access is granted. In some cases, the training should be in the form of classroom instruction. In other cases, interactive computer sessions or well-written and understandable brochures may be sufficient, depending on the risk and magnitude of harm related to the subject matter..

(3) Refresher awareness training frequency shall be determined by the Director, AIS Security.

(4) Each new user of a general support system in some sense introduces a risk to all other users. Therefore, each user should be versed in acceptable behavior -- the rules of the system -- before being allowed to use the system.

(5) Training should be tailored to what a user needs to know to use the system securely, given the nature of that use, and how to get help in the event of difficulty with using or security of the system.

(6) Access provided to members of the public should be constrained by controls in the applications through which access is allowed, and training should be within the context of those controls.

(7) Additional awareness training will be provided when significant changes occur in AIS security environments or procedures, or to employees who assume new positions or assignments dealing with information at a higher level of sensitivity.

(8) Security awareness training should include the following topics, as appropriate.

(a) Common AIS threats, vulnerabilities, and risks.

(b) Information accessibility, handling, labeling, and storage protection considerations.

(d) AIS data access controls and rules of behavior.

(e) Procedures for disaster recovery and contingency operations plans.

(f) AIS security configuration management and control requirements.

(g) AIS-related security incident reporting requirements and procedures.

(9) Specialized training is required for all individuals given access to an application, including members of the public. It should vary depending on the type of access allowed and the risk that access represents to the security of the application and information in it. This training will be in addition to that required for access to a support system. Such training may vary from a notification at the time of access (e.g., for members of the public using an information retrieval application) to formal training (e.g., for an employee that works with a high-risk application).

(10) All personnel who design, develop, operate, or maintain sensitive AIS will be provided security training appropriate to the level of risk they present to Customs AIS. The training shall address the types of security and internal control techniques that ought to be incorporated into AIS development, operation, and maintenance.

(11) AIS Security Administration should be consulted for guidance on achieving training objectives.

3.7 SECURITY OVERSIGHT

The ADP Steering Committee, Security Subcommittee, is the oversight authority for Customs AIS Security Program. (See also: Section 2.2(2))

The AIS Security Officer conducts ongoing day-to-day operational policy-related security oversight activities and ensures that periodic AIS security reviews are conducted.

(1) The AIS Security Officer must develop and maintain, with the assistance of AIS Security Administration, IRM, and SPD managers, a list of AISs requiring accreditation. This list must be annually verified and should include the recommended accreditation priority and AA identity for each AIS.

(2) Given the global nature of Customs AIS resources, the appointment of DSOs provide local oversight and help to ensure adherence to AIS security policy. They provide points-of-contact for accomplishing AIS security-related activities.

(3) Customs Office of Information and Technology (OIT) is a sign-off to AIS-related acquisitions and will enforce AIS security as part of the procurement process.

The AIS Security Officer reviews and authorizes all security-related acquisitions for sensitive AISs to ensure that the appropriate AIS security requirements are included in the specifications for the operation of an AIS installation facility, equipment, application system, or the acquisition of AIS hardware, software, or related services.

(4) The Contracting Officer Technical Representative (COTR) has contract oversight and will ensure that the contractor-related AIS security requirements are followed throughout the contract life-cycle.

(5) The AIS security policy program is implemented through the following actions:

(i) appointment of DSOs;

(ii) acquisition reviews;

(iii) review and approval of security requirements to support AIS development;

(iv) preparation, approval, and implementation of certification requirements;

(v) preparation and approval of accreditation documentation;

(vi) security training reviews;

(vii) security controls and auditing; and

(viii) security incident reporting.

CHAPTER 4

MINIMUM SECURITY REQUIREMENTS

The AIS security goal is to develop a functionally secure, efficient, cost-effective environment based on an assessment of security risks and safeguards. All AISs processing, storing, or transmitting sensitive information must meet the requirements of this policy through automated or manual means. More stringent requirements may be imposed based on a risk analysis.

This section documents the minimum security requirements for Customs AISs processing sensitive data with respect to: Facility, Personnel, Automated, and Telecommunications security.

4.1 FACILITY SECURITY

(1) The Security Programs Division (SPD), Security Management Branch, prescribes policies, procedures, and standards for the Customs facility security program.

(2) Facility security addresses the requirements to provide adequate physical and environmental controls based on the level of risk to the AISs supported in a facility, as identified by a risk analysis. The security controls must not be less than the minimum requirements discussed in this section, unless a written waiver has been granted by the Accrediting Authorities (AAs).

(3) For the purposes of this policy, an AIS facility includes physical space housing AIS equipment such as terminals, microcomputers, mainframe systems, communications equipment, or supporting environmental control utilities. Facilities also include data storage and AIS documentation libraries (e.g., off-site back-up storage facilities).

4.1.1 Physical

(1) Physical security is concerned with the measures designed to prevent unauthorized physical access to equipment, facilities, material, information, and documents, and to safeguard them against espionage, sabotage, damage, tampering, theft, and other covert or overt acts. AIShardware, software, documentation, and all sensitive information handled by the AIS will be protected to prevent unauthorized disclosure, modification, or destruction. AIS hardware, software, or documentation must be protected if access to such resources may reveal information that can be used to eliminate, bypass, or otherwise render ineffective the security safeguards (countermeasures) used to protect sensitive information.

(2) Sensitive Customs information, while operational, must be processed, stored, or transmitted in physical spaces (i.e., buildings, communications facilities, etc.) which are under exclusive Customs control, including MOUs (Memorandum of Understanding) and contractual agreements. When not in operation, or under the direct control of an authorized person, Customs AISs and information must be protected by control systems and measures consistent with Customs facility security program.

Prior to conducting sensitive AIS operations at any location, AIS security planning must consider the facility security program as part of the accreditation process.

(3) For all types of facilities where sensitive information is stored, processed, or transmitted, physical access will be restricted to those individuals who are authorized according to the personnel security requirements and who are necessary to complete assigned job functions and related duties. (See also: Section 4.2)

All other personnel granted facility access must be properly escorted and restricted to those areas necessary to complete their tasks. Sensitive Customs information must be protected from unauthorized disclosure to such persons.

4.1.2 Environmental

(1) Environmental controls address the requirements to provide appropriate temperature and humidity controls, fire protection, power, and natural disaster protection necessary to ensure the continuity of operations for AIS facilities and equipment.

(2) Areas that support desktop AIS equipment generally require environmental controls specified for human safety and comfort. Additional physical, electrical, temperature, and humidity controls may be needed to ensure reliable AIS operations in some cases.

(3) Facilities supporting large-scale AIS operations, such as mainframe computers and telecommunication facilities, may require additional environmental controls as determined by operational needs and risk analysis. The following additional controls should be considered:

(a) Fire prevention, detection, suppression, and protection measures.

(b) Water hazard detection, prevention, and corrective measures.

(d) Temperature and humidity controls.

(e) Protective or control measures from the effects of earthquakes, lightning, windstorms, and other natural disasters.

(f) Protective or control measures from the effects of industrial, environmental, or other physical conditions which might seriously impact normal AIS operations.

(g) Housekeeping protection from dirt, dust, and other contaminants.

(h) Personnel safety features.

4.2 PERSONNEL SECURITY

(1) The Security Programs Division (SPD) sets policy and provides procedures and guidance in support of Customs personnel security program. Prior to conducting AIS operations, and as part of the accreditation process, AIS security planning must consider the personnel security program.

(2) All personnel entrusted with the management, operation, maintenance, or use of a Customs AIS processing, storing, or transmitting sensitive information require appropriate personnel security approval. [USCS 51000-05]

(3) Customs personnel and Non-Customs contractor personnel entrusted with the management, operation, maintenance, or use of sensitive Customs AISs require an appropriate authorization and must have a completed Background Investigation (BI). [USCS 1460-010]

(4) Non-Customs government personnel entrusted with the management, operation, maintenance, or use of sensitive Customs AISs require an appropriate authorization and background investigation.

(5) Non-Customs personnel (members of the trade community), who use Customs AISs must be authorized in writing by the AIS Security Officer, Process Owner, or some other formalized process that assures appropriate authorization.

(6) Non-Customs AIS technical support personnel who are required to perform maintenance on Customs AISs within Customs-controlled facilities may be approved for unescorted access based on an appropriate authorization and a completed BI.

(7) AIS security training must be provided to all personnel who manage, operate, develop or use AISs. (See also: Section 3.6)

4.3 AUTOMATED SECURITY

This section establishes near-term requirements and long-term goals to improve the security of Customs AISs through increasing reliance on automated security features. The minimum security requirements addressed in this section are feasible in the current Customs AIS environment. As technology evolves, the desirable security features identified in this section should be assessed during AIS planning and development.

4.3.1 Minimum Security Requirements

National Policy on Controlled Access Protection. The White House, National Telecommunications and Information Systems Security Committee, 07/15/87, directs that by Federal agencies must provide automated Controlled Access Protection (C2 level) for all sensitive or classified information processed or maintained by AIS, when all users do not have the same authorization to use the sensitive information. [NTISSP 200]

(1) AISs used for the processing of sensitive information must have the security functionality of the C2 level of trust, as defined in the Department of Defense (DoD), Trusted Computer System Evaluation Criteria (TCSEC). [5200.28-STD]

(a) In cases where C2 functional security requirements are time consuming, technically unsound, or adversely affect operations to an unacceptable degree, other safeguards may be substituted if they maintain the level of system security commensurate with the sensitivity of the data. The AIS Security Officer must approve exceptions (written waiver) to C2 functional security requirements for sensitive AIS.

(See also: Appendix C)

(b) The National Computer Security Center (NCSC) Technical Guide, Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria (TNI-TCSEC, commonly known as the "red book"), provides guidance on achieving C2 functionality in networks. [NCSC-TG-005]

(2) The design of AISs that process, store, or transmit sensitive information must include at a minimum, the automated security features discussed in this section. Security safeguards will be in place to ensure each person having access to a sensitive AIS is individually accountable for their actions on the system.

(a) User Identification. User access will be controlled and limited based on positive user identification and authentication mechanisms that support the minimum requirements of access control, least privilege, and system integrity.

(b) Authentication. For AIS requiring authentication controls, the AIS will ensure that each user is authenticated prior to AIS access. The preferred method for authenticating users is a password system where authentication is done each time the password is used. More sophisticated authentication techniques, such as "smart cards," MISSI (Multilevel Information Systems Security Initiative) technology (Fortezza, Capstone, etc.), biological recognition systems (retina scanners, hand print, voice recognition, etc.), must be cost-justified through the risk analysis process. [MISSI]

(c) Audit Records. AIS transactions are subject to recording and routine review for inappropriate or illegal activity. Audit trail records should be sufficient in detail to facilitate reconstruction of events if compromise or malfunction occurs, or is suspected, and should be reviewed as specified in the AIS security plan. The audit trail records should contain at least the following information.

(i) Identifier of each user and device accessing or attempting to access an AIS.

(ii) The time and date of the access and of the logoff.

(iii) Identify activities that might modify, bypass, or negate AIS security safeguards.

(iv) Log of security-relevant actions associated with processing.

(d) Object Reuse. Sensitive AIS must clear memory and/or data storage areas (RAM, DASD, tape, R/W Optical, etc.) prior to reallocation of the area to a different user. This prevents one user from obtaining residual data of another user.

(e) Access Control. Sensitive AIS may implement additional discretionary access control (DAC) measures such as file passwords, access control lists, disk encryption, or other techniques, as defined in the approved system security plan.

(3) For sensitive AIS the following Warning Banner (exactly as worded in Figure 3) must be displayed to users at logon time, followed by a pause requiring manual intervention to continue. This addresses the concern that users are informed that all Customs AISs are subject to monitoring and that by using the AIS they consent to such monitoring.

(4) Automatic interactive-session timeout (logoff) will be provided for all general support and/or sensitive AISs. This will lockout a user session after an interval of inactivity, not to exceed the time interval and restart requirements specified in the AIS security plan. System logon will be required to re-access the AIS.

(5) Interconnections between sensitive Customs AISs and non-Customs AISs must be established through controlled interfaces and will be accredited at the highest security level of information on the network. Consult the AIS Security Officer for guidance on establishing controlled interfaces.

Controlled interface functions are a combination of gateway and guard functions.

Gateways provide secure points of interconnection between networks, connected peripheral devices, remote terminals, or remote hosts, and provide a reliable exchange of information to allow secure interconnections between components.

Automated guard processors and security filters (e.g., firewall) are software, combined hardware/software techniques, or specialized hardware that filter information in a data stream based on associated security information and/or data content.

4.3.2 Security Assurances

(1) AISs will be examined when received from the vendor(s) and before being placed into operation. The following areas must be considered:

(a) Hardware. An examination will result in assurance that the equipment appears to be in good working order and has no components that might be detrimental to the secure operation of the resource when placed under Customs control and cognizance. Subsequent changes and developments which affect security may require additional examination.

(b) In-house Developed Software or Government-Off-The-Shelf (GOTS). New or significantly changed software developed by or specifically for Customs or the Government will be subject to testing and review at all stages of the development, as required by the SDLC. [USCS 5500-4]

(c) Commercial-Off-The-Shelf Software (COTS). Commercially procured software will be examined to assure that the software does not contain features which might be detrimental to AIS security. Security-related software will be examined by Customs authorized personnel to assure that the security features function as specified.

(2) Customs endorses the use of products from the Evaluated Products List (EPL) of the National Computer Security Center (NCSC). EPL products are computer systems, software, or components that protect information while it is being stored or processed.

When certified as properly implemented through the process discussed in Section 3.4, these products will be accepted as meeting the security requirements for the portion of the sensitive AIS where they are used.

(3) When EPL products are not specified or used for sensitive AIS, the AIS security plan must include a functionality statement and implementation schedule of how the C2 security level functionality will be achieved. The statement will become part of the accreditation package and must address the following EPL evaluation areas.

(a) Confidence in software source. In acquiring software resources to be used as part of a sensitive AIS, consideration will be given to the level of confidence placed in the vendor to provide a quality product, to support the security features of the product, and to help in the correction of any flaws.

(b) Security performance testing. Security performance testing includes both certification testing that is performed before the AIS is accredited and ongoing performance testing that is performed on a regular basis.

(c) Security penetration testing. In addition to testing the performance of the AIS, there will be testing to attempt to penetrate the security safeguards of the system. The test procedures will be documented in the test plan for certification and in the ongoing test plan.

(d) Life-cycle assurance. The development of hardware, firmware, and software will be conducted under life-cycle control and management.

(4) A configuration management (CM) system is required to preserve the AIS accreditation integrity and maintain control of changes to any of the AIS features that may alter the accreditation status. Examples of CM activities include security-related hardware changes, or changes to any line of source or object code of the security-related software. The CM system will record by whom, for what reason, and when the change is made. Documentation of the security-related hardware and/or software design will be maintained and kept current. [NCSC-TG-006]

4.3.3 Desirable Security Features

(1) AIS planning must consider technological advances in security features. The planning process will be documented and approved via the AIS security plan.

(2) Interoperability with external systems must consider support for digital signature standards (DSS), nonrepudiation in messaging systems, and data encryption issues as they relate to interagency communications or interoperability.

(3) Continuous On-Line Automated Monitoring and Warning functions for sensitive AIS can provide real-time use monitoring (audit) and real-time warning to the DSOs of suspected AIS misuse.

(4) Network Access Control Features should address the following areas, to achieve C2 level security of communications paths:

(a) Identification and Authentication Forwarding. Reliable forwarding of the identification should be used between AISs when users are connecting through a network. When identification forwarding cannot be verified, a request for access from a remote AIS should require authentication before permitting access to the system.

(b) Protection of Authenticator Data. In forwarding the authenticator information and any tables (e.g., password tables) associated with it, the data should be protected from access by unauthorized users (e.g., by encryption) to ensure its integrity.

4.4 ADMINISTRATIVE SECURITY

Administrative security consists of the controls and operational procedures used with or in place of computer security features. Administrative security controls must be documented in the AIS security plan, Security Features User's Guide (SFUG), and Trusted Facility Manual (TFM) for each accredited AIS.

4.4.1 Accountability and Access Control Criteria

The DSO will establish access control criteria and administrative procedures to limit access to information processed, stored, or transmitted by sensitive Customs AISs. These activities are documented in the AIS security planning process, approved by the AIS Security Officer, and accredited as discussed in Section 3.4 and should include at least the following:

(1) The access control criteria identify who is authorized AIS access and who is responsible for approving such access.

(a) The individual who requires access must possess the appropriate security authorization and have a valid need-to-know.

(b) The AIS security features must have the capability to restrict the user's access to only that information which is necessary for scope of the job or assignment.

(2) Customs and contractor personnel who access sensitive Customs AISs must have a completed BI (discussed in Section 4.2). Personnel must only be granted access to AISs for which they have a valid need-to-know based on their operational needs (i.e., principle of least-privilege.).

(3) Customs AISs are generally designed for the use of Customs personnel, but by special arrangements Customs may authorize certain types of access to other Federal, State, local, or international law enforcement agencies, other government agencies, private contractors, and trade community members in support of particular operations.

Written requests for special access must be submitted to the appropriate Customs Security Administrator who coordinates the AIS security process for the sponsoring organization. The Security Administrator will ensure that such requests meet the following criteria.

(a) The individual for whom access is requested must have appropriate security authorization for the information or functions which are being requested.

(b) The individual must have a valid need-to-know (i.e., access is an operational necessity) documented in the application by the sponsoring organization.

(c) The AIS security features have the capability to restrict the user's access to only information and/or functions appropriate for the authorized activities.

(d) If the AIS access is for members trade community, it must be based on limits as specified in formal agreements with Customs.

(4) Some Customs AISs are designed for the support of the law enforcement, trade communities (e.g., TECS, ACS), and other agencies. Access requirements, controls, and procedures are defined for each system and documented in its System Security Plan. Reference the appropriate AIS support documentation for details related to such systems.

4.4.2 Software and Data Security

(1) All executable software used on sensitive Customs AISs should be obtained through authorized procurement channels. Software acquired by any other means (e.g., public domain software, bulletin board services, personally owned software [developed or purchased]) is restricted and must be approved in writing by AIS Security Administration as an operational necessity.

(2) Safeguards must be in place to detect and minimize inadvertent or malicious modification or destruction, or attempts to do so, of a sensitive AIS's application software, operating system software, and critical data files. The safeguards should achieve the integrity objectives andbe documented in the AIS security plan.

(a) Executable software authorized to run on a sensitive Customs AIS will be identified in the AIS security plan.

(b) The level of protection must be commensurate with the sensitivity of the information processed.

(c) At a minimum, essential data should be backed-up and the media stored physically separate from the AIS (preferably at an off-site location). Appropriate AIS security controls must be in place to assure viability of such back-ups.

(3) Virus and malicious code (software) prevention and control measures, commensurate with the identified level of risk, will be employed to protect the integrity of the software and data for applicable AIS.

(a) The AIS Security Officer manages the virus protection program for Customs and should be contacted for approved prevention and control measures (e.g., behavior detection, scanning, cleanup techniques and/or procedures) if there is a suspected or known malicious code (software) threat.

(b) Identified incidents of malicious code (software), or virus infections should be reported promptly to the DSO, AIS Security Officer, and/or IA, as appropriate.

(c) Prior to introduction into or use by Customs, AIS data recording media will be scanned for malicious code (software), including:

(i) all Customs-seized AIS machines and media,

(ii) all removable AIS magnetic or optical recording media (e.g., floppy disks, CD-ROM, etc.), regardless of source, and

(iii) all fixed AIS storage devices (e.g., hard drives, R/W Optical, etc.), on a periodic basis.

(4) Use of copyrighted software will comply with copyright laws and license agreements.

(5) Introduction of data from sources and/or in formats other than those specified in the appropriate AIS security plan (e.g., financial data received from financial institutions) must be approved in writing by the AIS Security Officer as an operational necessity. These activities must be in conformance with the accreditation of the AIS and FOIA/PA (Freedom of Information Act/Privacy Act) requirements.

(6) To maintain software integrity, proper configuration management (CM) and controls must be used to monitor software installation and updates. This process will provide a historical record of software changes; helping to ensure that the software functions as expected, is maintained, and that only authorized software is permitted on the AIS.

4.4.3 Technical Support and Maintenance

(1) Technical support and maintenance activities for Customs AIS must ensure that:

(a) Hardware and software maintenance activities do not affect the integrity of existing safeguards or permit the introduction of security exposures into an AIS (e.g., computer viruses, Trojan Horses, logic bombs, malicious code, etc.).

(b) Sensitive Customs AIS electronic storage and memory devices are not released from Customs control without proper clearing procedures to remove residual data. Exceptions (waivers) must be approved by the AIS Security Officer.

(c) Automated (i.e., computer-connected) dial-up diagnostic maintenance of sensitive Customs AIS via remote communications between vendors and Customs AIS facilities is prohibited unless authorized by Principal Accrediting Authority (PAA) in the AIS Accreditation. The Accreditation should reference an approved contract, MOU, or other agreement when such a service is included.

(2) AIS technical support and maintenance work performed in Customs facilities (on-site) must be supervised by or under the control of Customs personnel knowledgeable in appropriate AIS operations.

On-site AIS technical support and maintenance personnel must meet the personnel security requirements. (See also: Section 4.2)

(3) AIS technical support and maintenance must be considered in AIS certification.

4.4.4 Portable Computer Equipment

Customs AIS portable computers, related types of equipment, and storage media must be restricted to the exclusive authorized Customs use. Unattended Customs AIS equipment and storage media must be secured in an appropriate manner commensurate with the sensitivity of the data, equipment, and authorized use. To the extent possible, such equipment and storage media must be kept in the possession of the individual to whom it is issued or charged out.

4.4.5 Classification and Controls

(1) Customs AISs that store, process, or transmit sensitive information must be adequately safeguarded to ensure that access to sensitive Customs information is restricted to Customs authorized personnel, and operated only by Customs authorized persons in facilities (physical space) under Customs authorization or control.

(2) When not under the control of Customs authorized personnel, Customs sensitive AISs and related equipment must, at a minimum, be secured as follows:

(a) Microcomputers, terminals, displays, and related AIS equipment which might provide unauthorized access to sensitive data or resources, must be turned off or otherwise made unaccessible. Additional appropriate security control measures may be necessary in some situations. Exceptions (waivers) must be part of the accreditation statement or separately approved by the AIS Security Officer.

(b) Diskettes, tapes, removable storage devices, printer ribbons or laser cartridges, and other AIS media which contain sensitive information must be labeled and secured commensurate with the highest level of information stored on the device. Destruction of such media must be appropriate to the level of sensitivity of the data stored on it.

4.4.6 External Labels

In an AIS environment where no classified information is processed or stored, special security labels with the word "Unclassified," are not required to identify that the storage media contains unclassified information. However, for some categories of SBU data, special identification labels are required. Reference Safeguarding Classified Information Handbook, for the appropriate procedures.

[USCS HB 1400-03]

The term "unclassified" is not a security classification, but is a category of data within which are several subcategories, including sensitive but unclassified (SBU) and public information.

Sensitive but unclassified (SBU) information is restricted to authorized persons with a need-to-know and requires appropriate controls as explained in this manual.

4.4.7 Customs Work Performed at non-Customs Locations

When operational necessity requires that Customs authorized work be performed at non-Customs controlled locations (e.g., field assignment, work at home, etc.), the following policies apply and associated risks must be appropriately managed.

(1) Customs management must determine that required security controls and documentation are in place for authorized AIS operations and that SBU information is properly protected. Although current technology makes it feasible to address these requirements, providing adequate safeguards and conducting related activities for individual AISs may not always be cost-effective.

AIS security control documentation includes the following.

(a) System security plan.

(b) Risk analysis.

(d) Security procedures.

(e) Certification.

(f) Accreditation.

(2) AIS equipment (whether or not Customs owned) used to process SBU at non-Customs controlled locations must meet the security requirements for sensitive Customs AISs as presented in this policy manual.

(3) Authorized use of Customs owned computer equipment at home is permitted when such usage is consistent with the policy as presented in this manual.

4.4.8 Use of Non-Customs Owned AISs

(1) It is Treasury policy that, "Personally-owned computers and software will not be used to process sensitive but unclassified (SBU) information without the approval of the Principal Accrediting Authority." (Reference: TD P 71-10, Chap. VI, Section 4.D.1).

Treasury policy defines, Personally-owned computers or software as, "Computers or software purchased with non-government funds, except those turned over for exclusive U.S. Government control and use and where the hard-drive will be properly erased when the system is no longer in U.S. Government use."

(Reference: TD P 71-10, Appendix B. Definition updated 11/24/95).

(2) It is Customs policy that, non-Customs owned computers or software will not be used to process, access, or store Sensitive But Unclassified (SBU) information without the written approval of the Principal Accrediting Authority (PAA).

(a) Policy exceptions (waivers) must be approved by the PAA who assumes the associated risks for authorizing the use.

(b) The protection requirements for data on Customs owned equipment apply equally to the protection of data when used on non-Customs owned equipment.

4.5 TELECOMMUNICATIONS SECURITY

The Federal government is developing appropriate security policies and infrastructures that deal with the rapidly changing field of telecommunications. Under the auspices of the White House Office of Science and Technology Policy, the National Information Infrastructure Task Force (NITF) is a driving force in this effort. The NITF includes high-level representatives of Federal agencies that play a major role in the development and application of information and telecommunications technologies. [GAO94285; GAO9523]

4.5.1 Information System Standards

It is the policy of the Department of the Treasury to comply with all mandatory Federal Information Processing Standards (FIPS), mandatory Federal Telecommunications Standards (FED-STDs), voluntary FIPS, FED-STDs, American National Standards Institute (ANSI), or other information system standards and guidelines to the extent they are determined to be cost-effective and appropriate for the intended use. A waiver process is defined in Treasury Information Systems Standard Program, 8/23/89. [TD 87-01; COHEN]

4.5.2 Network Connections

Telecommunication connections between Customs AISs and non-Customs AISs or networks, public or private, may be authorized by the AIS Security Officer under the following conditions:

(1) Non-sensitive Customs AIS, when operated in a dedicated security mode, must be locally documented, including the administrative approval of the AIS Security Officer and a technical description of the connection(s). Example: microcomputers, PCs, etc., that do not contain or process SBU data and are not connected physically or logically to any other Customs AIS or network (Treasury or Customs).

(2) All other Customs AIS connections to non-Customs networks must be approved by the AIS Security Officer, on a case-by-case basis. The AIS Security Officer will ensure that the appropriate safeguards are in place and that documentation, such as license agreements, memoranda of understanding (MOU), interconnection agreements, etc., are executed on behalf of Customs, as part of the approval process. Example: Customs AIS access to the National Information Infrastructure (NII) or commercial information databases (e.g., LEXIS/NEXIS, Dun & Bradstreet Business records, D&B Worldbase, etc.).

4.5.3 Internet Services

Treasury policy: Issued April 28, 1995, by the Deputy Assistant Secretary for Information Systems. [TD INTERNET]

Treasury operating policy requires that any access to the Internet services from Treasury AIS (including Customs) be provided via protected Internet gateways (access control mechanisms) that have been approved by the Office of Telecommunications Management (OTM).

Exceptions must be approved in writing by the Director, OTM.

Customs policy:

In addition to Treasury policy, Customs owned or controlled AISs may only access the Internet via Customs approved gateways.

This limitation means that Customs owned, controlled, or authorized computer equipment, regardless of its location or means of connection to any network or system, may not be used to access the Internet, directly or indirectly (e.g., via service providers such as CompuServe, AOL, etc.) unless such connection is via a Customs approved Internet gateway (i.e., firewall). While the configuration of some networks make it technically possible to access the Internet without going through an approved gateway, such access is not authorized.

Exceptions to this policy must be approved in writing by the Director, OTM, U.S. Treasury Department. [TD INTERNET]

4.5.4 Electronic Mail (E-Mail)

Government projects and commercial products for secure electronic mail (E-Mail) systems are undergoing rapid development and will be available in the coming years. Until such products are implemented, users are cautioned NOT to send sensitive information via E-Mail.

4.5.5 Facsimile (FAX)

Sensitive information will only be transmitted via a secure facsimile system (e.g., encrypted or via a protected network). Commercial-off-the-shelf (COTS) software and hardware are available to provide the necessary safeguards and should be employed as appropriate.

4.5.6 PBX and Voice Mail Systems

Private Branch Exchanges (PBX) and Voice mail systems do not currently meet standard security specifications and are not generally considered secure systems. They are susceptible to unauthorized access and messages left on a voice mail system should contain the least amount of information possible. Do not leave any information on a voice mail system that, if compromised, could damage Customs mission. Report suspected unauthorized access attempts to AIS Security Administration.

PBX systems must be physically secured and system security features configured (to the extent possible for a specific system) to prevent unauthorized access to dial-tones, modems, or other AIS access. (See also: Appendix D. Good Security Practices).

Voice Mail and Voice Interactive Response systems must be configured (to the extent possible) to prevent unauthorized access to dial-tones, modems, or other AIS access.

(See also: Appendix B. Good Security Practices).

4.5.7 Communications Security (COMSEC)

COMSEC is intended is to deny unauthorized persons information derived from telecommunications of the United States Government related to national security and to ensure the authenticity of such communications. COMSEC issues should be directed to the Communications Security Management Branch, Orlando, FL. [USCS 4300-09]

CHAPTER 5

SECURITY INCIDENTS AND VIOLATIONS

Definition: AIS Security Incident. An AIS security incident is any event and/or condition that has the potential to impact the security and/or accreditation of an AIS and may result from intentional or unintentional actions.

Examples include: unauthorized attempts to gain access to information; introduction of malicious code or viruses into Customs AISs; loss or theft of computer media; or the failure of an AIS security function to perform as designed. For reporting purposes, malicious code (software) incidents include any detection of malicious code, whether detected on magnetic media prior to the media's entry into a Customs AIS or after infection of the AIS, and any actual execution of malicious code.

Definition: AIS Security Violation. An event which may result in disclosure of sensitive or classified information to unauthorized individuals, or that results in unauthorized modification or destruction of system data, loss of computer system processing capability, or loss or theft of any computer system resources.

(See also: TD P 71-10, Chapter III.4)

(1) Customs employees, contractors, and/or users should report security-related incidents and/or violations through the appropriate supervisory channels to the DSOs, Security Administrators, AIS Security Officer, or Internal Affairs (IA), as appropriate. The AIS Security Officer will maintain the appropriate records and address the impact of the security incidents on the accreditation status of related AISs. Additional security safeguards to reduce generic risks may be recommended, as required.

(2) Additionally, malicious code (software) and virus infection incidents on Customs AIS (i.e., mainframes, microcomputers, networks, PCS, floppy disks or other media, etc.) should be promptly reported to the AIS Security Officer.

(3) Customs employees may be subject to disciplinary action for failure to comply with Customs AIS security policy, whether or not the failure results in criminal prosecution.

AIS security-related violations are addressed in the Treasury Standards of Ethical Conduct for Employees of the Executive Branch and the Customs Conduct and Employee Responsibilities. Such violations should be reported through the appropriate supervisory channels to the AIS Security Officer and/or IA, as appropriate. [TD ETHICS; USCS 51000-05]

(4) Non-Customs employees who fail to comply with this policy are subject to having their access to Customs AISs and facilities terminated, whether or not the failure results in criminal prosecution.

(5) Any person who improperly discloses sensitive or classified information is subject to criminal and civil penalties and sanctions under a variety of laws (e.g., Privacy Act ...).

(This Page Intentionally Left Blank)

GLOSSARY

Editor's note: Computer terms have evolved and become more clearly defined during the past decade. The referenced definitions are from recent publications of established sources, and are generally preferred.

Source references:

Glossary of Computer Security Terminology, developed by the National Security Telecommunications and Information Systems Security Committee (NSTISSC) and published by NIST as NISTIR 4659. Available from NTIS as PB92-112259.

Glossary for Computer Security Terms. National Technical Information Service (NTIS), FIPS PUB 39, Springfield, VA., 02/15/76. Withdrawn 4/93. Replacement is FIPS 11-3.

Introduction to Certification and Accreditation. National Computer Security Center (NCSC), NCSC-TG-029, Ver. 1, NSA, Ft. George G. Meade, MD., January 1994.

Treasury Security Manual, TD P 71-10, Appendix B, 1993.

Access

A specific type of interaction between a subject and an object that results in the flow of information from one to the other. The capability and opportunity to gain knowledge of, or to alter information or materials including the ability and means to communicate with (i.e., input or receive output), or otherwise make use of any information, resource, or component in a computer system.

Access Control

The process of limiting access to the resources of a system to only authorized persons, programs, processes, or other systems. Synonymous with controlled access and limited access. Requires that access to information resources be controlled by or for the target system. In the context of network security, access control is the ability to limit and control the access to host systems and applications via communications links. To achieve this control, each entity trying to gain access must first be identified, or authenticated, so that access rights can be tailored to the individual.

Accreditation/Approval

The official management authorization for operation of an AIS. It provides a formal declaration by an Accrediting Authority that a computer system is approved to operate in a particular security mode using a prescribed set of safeguards. Accreditation is based on the certification process as well as other management considerations. An accreditation statement affixes security responsibility with the Accrediting Authority and shows that proper care has been taken for security.

Accrediting Authority (AA)

The official who has the authority to decide on accepting the security safeguards prescribed for a computer system or that official who may be responsible for issuing an accreditation statement that records the decision to accept those safeguards.

See also: Designated Approving Authority (DAA), Principal Accrediting Authority.

Adequate Security

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 agency operate effectively and provide appropriate confidentiality, integrity, and availability, through the use of cost-effective management, personnel, operational and technical controls. [OMB A-130, AIII]

Administrative Systems

An automated Customs system to provide support in areas of accounting, personnel, payroll, logistics and other support services.

ADP

Automatic Data Processing. See also: Automated Information System

AIS

See: Automated Information System.

AIS Owner

The official who has the authority to decide on accepting the security safeguards prescribed for an AIS and is responsible for issuing an accreditation statement that records the decision to accept those safeguards.

See also: Accrediting Authority (AA), Application Owner, Process Owner, PAA, DAA.

AIS Security

Measures or controls that safeguard or protect an AIS against unauthorized (accidental or intentional) disclosure, modification, destruction of the AIS and data, or denial of service. AIS security provides an acceptable level of risk for the AIS and the data contained in it. Considerations include: 1) all hardware and/or software functions, characteristics, and/or features; 2) operational procedures, accountability procedures, and access controls at all computer facilities in the AIS; 3) management constraints; 4) physical structures and devices; and 5) personnel and communications controls.

Application

A software organization of related functions, or series of interdependent or closely related programs, that when executed accomplish a specified objective or set of user requirements. Customs applications include: Automated Commercial System (ACS), Automated Export System (AES), Treasury Enforcement Communication Systems (TECS), and Administrative Systems (AS). [USCS 5500-05] See also: Major Application, Process.

Application Owner

The official who has the responsibility to ensure that the program or programs which make up the application accomplish the specified objective or set of user requirements established for that application, including appropriate security safeguards.

See also: Accrediting Authority (AA), Process Owner.

Audit

To conduct the independent review and examination of system records and activities.

Audit trail

A set of records that collectively provides documentary evidence of processing. It is used to aid in tracing from original transactions forward to related records and reports, and/or backwards from records and reports to their component source transactions.

Automated Commercial System (ACS)

A joint public/private data processing system used by Customs and the import trade community to process millions of commercial cargo shipments entering U.S. commerce each year.

Automatic Data Processing (ADP)

The assembly of computer hardware, firmware, and software used to categorize, sort, calculate, compute, summarize, store, retrieve, control, process, and/or protect data with a minimum of human intervention. ADP systems can include, but are not limited to, process control computers, embedded computer systems that perform general purpose computing functions, supercomputers, personal computers, intelligent terminals, offices automation systems (which includes standalone microprocessors, memory typewriters, and terminal connected to mainframes), firmware, and other implementations of AIS technologies as may be developed: they also include applications and operating system software. See also: Automated Information System (AIS).

Automated Export System (AES)

A data processing system used by Customs to provide automatic release of cargo that is subject to U.S. export regulatory requirements, collect export data and statistics for use in law enforcement, illegal chemical interdiction, export verification, revenue collection, and other activities.

Automated Information System (AIS)

An AIS is an assembly of computer hardware, software, and/or firmware configured to collect, create, communicate, compute, disseminate, process, store, and/or control data or information. Examples include: information storage and retrieval systems, mainframe computers, minicomputers, personal computers and workstations, office automation systems, automated message processing systems (AMPSs), and those supercomputers and process control computers (e.g., embedded computer systems) that perform general purpose computing functions. [TD P 71-10]

Authenticate/Authentication

1) The process to verify the identity of a user, device, or other entity in a computer system, often as a prerequisite to allowing access to resources in a system.

2) A process used to verify that the origin of transmitted data is correctly identified, with assurance that the identity is not false. To establish the validity of a claimed identity.

Authenticated user

A user who has accessed an AIS with a valid identifier and authentication combination.

Authorization

The privileges and permissions granted to an individual by a designated official to access or use a program, process, information, or system. These privileges are based on the individual's approval and need-to-know.

Authorized Person

A person who has the need-to-know for sensitive information in the performance of official duties and who has been granted authorized access at the required level. The responsibility for determining whether a prospective recipient is an authorized person rests with the person who has possession, knowledge, or control of the sensitive information involved, and not with the prospective recipient.

Availability

The property of being accessible and usable upon demand by an authorized entity. Security constraints must make AIS services available to authorized users and unavailable to unauthorized users.

Back-up

A copy of a program or data file for the purposes of protecting against loss if the original data becomes unavailable.

Back-up Operation

A method of operations to complete essential tasks as identified by a risk analysis. These tasks would be employed following a disruption of the AIS and continue until the AIS is acceptably restored.

See also: Disaster Recovery, Contingency Operations.

Bacteria

A malicious computer program that consumes AIS resources by replicating itself. The program does not explicitly cause damage to files but replicates itself, thereby denying normal availability of AIS resources. See also: Virus, Worm, Trojan Horse, Malicious Code, Trap Door.

Baud

The signaling rate of a communications device, such as a modem, as measured by the changes per second of an event (usually an electrical or optical change). Using encoding the bits-per-second rate can be multiples of the Baud rate.

Bits-per-second

The signaling rate of a communications device, such as a modem, measured by binary digits transfers per second. Using encoding, bits-per-second rate can be multiples of the Baud rate.

See also: Malicious Code.

Write

A fundamental operation that results only in the flow of information from a subject to an object.

NONE AT THIS TIME

(This Page Intentionally Left Blank)

BIBLIOGRAPHY

The following laws, regulations, standards, policies, directives, guidelines, and references are the basis for the U.S. Customs Service AIS Security Policy Manual, HB 1400-04.

Note: The following list is sorted alphabetically by Reference ID.

Reference ID Document Title

[CHES94] William R. Cheswick and Steven M. Bellovin. Firewalls and Internet Security. Addison-Wesley, Reading, MA, 1994.

[COHEN] Information Technology Management Reform Act of 1996. Wash.,D.C. Also known as the "Cohen Bill."

[EO 12958] Office of the President, Classified National Security Information. EO 12958, Wash., DC, April 17, 1995, (Revoked EO 12356, 04/06/82). 9.o

[FIPS P 39] Glossary for Computer Security Terms. U.S. Department of Commerce, National Technical Information Service (NTIS), FIPS PUB 39, Springfield, VA., 02/15/76.

[GAO94285] Information Superhighway: Issues Affecting Development. GAO Report. GAO/RCED-94-285.

[GAO9523] Information Superhighway: An Overview of Technology Challenges. GAO Report. GAO/AIMD-95-23

[MISSI] MISSI Phase 1. NSA, Ft. George G. Meade, MD., 1994.

[NCSC-TG-003] A Guide to Understanding Discretionary Access Control in Trusted Systems. NCSC, NCSC-TG-003, Ver. 1, NSA, Ft. George G. Meade, MD., September 1987.

[NCSC-TG-005] Trusted Network Interpretation. NCSC, NCSC-TG-005, Ver. 1, NSA, Ft. George G. Meade, MD., July 1987. aka. Red Book.

[NCSC-TG-006] A Guide to Understanding Configuration Management in Trusted Systems. NCSC, NCSC-TG-006, Ver. 1, NSA, Ft. George G. Meade, MD., March 1988.

[NCSC-TG-025] Data Remanence in Automated Information Systems. NCSC, NCSC-TG-025, Ver. 2, NSA, Ft. George G. Meade, MD., September 1991.

[NCSC-TG-027] A Guide to Understanding Information Systems Security Officer Responsibilities for AIS. NCSC, NCSC-TG-027, Ver. 1, NSA, Ft. George G. Meade, MD., May 1992.

[NCSC-TG-029] Introduction to Certification and Accreditation. NCSC, NCSC-TG-029, Ver. 1, NSA, Ft. George G. Meade, MD., January 1994.

[NCSC TR 79-91] Integrity in Automated Information Systems. NCSC, NCSC C TR 79-91, NSA, Ft. George G. Meade, MD., September 1991.

[NTISSP 200] National Policy on Controlled Access Protection. The White House. National Telecommunications and Information Systems Security Committee. 07/15/87.

[NIST 500-172] Todd, Mary Anne, and Constance Guitan, Computer Security Training Guidelines. NIST, SP 500-172, Gaithersburg, MD., 11/89.

[OMB A-123] Management Accountability and Control. Cir. A-123, Revised, Wash., DC, June 21,1995.

[OMB A-130] Management of Federal Information Resources. OMB Cir. A-130, Wash., DC, 1985, 1993, 1994.

[OMB A-130,AIII] Security of Federal Automated Information Resources. OMB Cir. A-130, Appendix III., Wash., DC, 02/08/96.

[OTA-TCT-606] Information Security and Privacy in Network Environments. U.S. Congress. Office of Technical Assistance. OTA-TCT-606. Wash., DC: GPO, September 1994.

[PL 100-235] Computer Security Act of 1987. 40 USC 759, 101 STAT 1724. PL 100-235, Wash., DC, 01/08/88.

[TD ETHICS] U.S. Treasury Department. Standards of Ethical Conduct for Employees of the Executive Branch. Wash., DC, 02/03/93.

[TD INTERNET] U.S. Treasury Department. Treasury Directive. MANAGING THE INTERNET ACCESS: Operating Policy for Bureau Telecommunications Managers and Information Resources Management Officials within the Department of the Treasury. 4/28/95.

[TD P 25-04] U.S. Treasury Department. Privacy Act Handbook. TD P 25-04, Wash., DC, 04/91.

[TD P 25-05] U.S. Treasury Department. Freedom of Information Act Handbook. TD P 25-05, Wash., DC, 06/93.

[TD 84-01] U.S. Treasury Department. Information Systems Development Life Cycle Manual. TD 84-01, Wash., DC, 07/94.

[TD 87-01] U.S. Treasury Department. Information Systems Standards Program. TD 87-01, Wash., DC, 08/23/89.

[TD P 71-10] U.S. Treasury Department. Security Manual. TD P 71-10, Wash., DC, 12/93.

[TD 85-03] U.S. Treasury Department. Risk Assessment Guidelines, Volumes I & II. TD 85-03, Wash., DC, June 1990.

[USCS PPP] U.S. Customs Service. People, Processes and Partnerships: A Report on the Customs Service for the 21st Century, Wash., DC, September 1994.

[USCS 96PLAN] U.S. Customs Service. Annual Plan Fiscal Year 1996.. Wash., DC, 10/95.

[USCS IRMPLAN] U.S. Customs Service. Strategic IRM Plan for Fiscal Years 1998-2002. Wash., DC, 04/96.

[USCS 1400-03] U.S. Customs Service. Safeguarding Classified Information Handbook. USCS HB 1400-03, Wash., DC, 02/91.

[USCS 1460-010] U.S. Customs Service. Access Requirements for Customs Automated Information Systems. USCS Directive 1460-010, Wash., DC, 09/11/92.

[USCS 4300-09] U.S. Customs Service. Communications Security (COMSEC) Handbook. USCS HB 4300-09, Wash., DC, 12/92. (Supersedes/rescinds USCS Directives 4350-01, 4350-02, and 4350-03, also Handbook dated 1/90).

[USCS 51000-05] U.S. Customs Service. Conduct and Employee Responsibilities. USCS Manual Transmittal 51000-05, Wash., DC, 12/29/77.

[USCS 5500-04] U.S. Customs Service. Systems Development Life Cycle Handbook. Office of Information Management, Springfield, VA., 1995.

[USCS 5500-05] U.S. Customs Service. Automated Information Systems Services Handbook. Office of Information and Technology, Springfield, VA., November, 1995.

[USCS 5500-07] U.S. Customs Service. Illegal Use of ADP and Telecommunications Systems. USCS Directive 5500-07, Wash., DC, 02/22/89.

[5 USC 552] Freedom of Information and Reform Act (FOIA). 5 USC 552. Wash., DC August 13, 1987.

[5 USC 552a-74] Privacy Act of 1974. 5 USC 552a, Wash., DC, 12/31/74.

[5 USC 552a-87] Privacy Act of 1974, As Amended. 5 USC 552a, PL 93-579, Wash., DC, 07/14/87

[18 USC 1030] Computer Fraud and Abuse Act of 1986. 18 USC 1030, PL 99-474, Wash., DC, 10/16/86.

[5200.28-STD] Department of Defense. Trusted Computer System Evaluation Criteria (TCSEC). DoD 5200.28-STD, NIST, Gaithersburg, MD., aka. Orange Book, 1985.

[WACK] Wack, John P. and Lisa J. Carnahan. Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls. NIST, SP 800-10, Gaithersburg, MD, December 1994.

Selected Readings

Note: The following list is sorted alphabetically by author, title, or department.

(Reference: GPO Manual of Style. March 1984).

A Guide to Understanding Identification and Authentication in Trusted Systems. NCSC, NCSC-TG-017, Ver. 1, NSA, Ft. George G. Meade, MD., September 1992.

A Guide to Understanding Object Reuse in Trusted Systems. NCSC, NCSC-TG-018, Ver. 1, NSA, Ft. George G. Meade, MD., July 1992.

A Guide to Understanding Security Testing and Test Documentation in Trusted Systems. NCSC, NCSC-TG-023, Ver. 1, NSA, Ft. George G. Meade, MD., July 1993.

A Guide to Understanding Trusted Distribution in Trusted Systems. NCSC, NCSC-TG-008, Ver. 1, NSA, Ft. George G. Meade, MD., December 1988.

A Guide to Understanding Trusted Recovery in Trusted Systems. NCSC, NCSC-TG-022, Ver. 1, NSA, Ft. George G. Meade, MD., December 1991.

A Guide to Writing the Security Features User's Guide for Trusted Systems. NCSC, NCSC-TG-026, Ver. 1, NSA, Ft. George G. Meade, MD., September 1991.

An Introduction to Computer Security: The NIST Handbook. NIST SP 800-12, Gaithersburg, MD., March 1995.

Assessing Controlled Access Protection. NCSC, NCSC-TG-028, Ver. 1, NSA, Ft. George G. Meade, MD., May 1992.

Bomb Threats and Physical Security Planning. U.S. Treasury Department, Bureau of Alcohol, Tobacco, and Firearms, ATF Publication 7550.2, Wash., DC, 07/87.

Computer Matching and Privacy Act of 1974. PL 100-503, Wash., DC, 1974.

Computer Matching and Privacy Protection Act of 1988. PL 100-503, Wash., D.C., 12/1988.

Computer Matching and Privacy Protection Amendments of 1990. PL 101-508, Wash., DC, 11/05/90.

Computer Viruses: Prevention, Detection, and Treatment. NCSC, C1 TR -001, NSA, Ft. George G. Meade, MD., March 1990.

Counterfeit Access Device and Computer Fraud and Abuse Act of 1984. PL 98-473, Chapter XXI - Access Devices and Computers, 18 USC 2101 and 2102a, Chapter 47, Wash., DC 10/12/84.

Department of Defense. Password Management Guidelines. CSC-STD-002-85, NSA, Ft. George G. Meade, MD., 04/12/85.

Department of Defense. Security Requirements for Automated Information Systems (AISs). DoD Directive 5200.28, DOD, Wash., DC, March 1988.

Department of Defense. Technical Rational Behind CSC-STD-003-85: COMPUTER SECURITY REQUIREMENTS -- Guidance for Applying the DoD Trusted Computer System Evaluation Criteria in Specific Environments. CSC-STD-003-85, NSA, Ft. George G. Meade, MD., June 1985.

Disclosure of Confidential Information Generally. Trade Secrets Act. 18 USC 1905, PL 102-660, Wash., DC, Amended 10/28/92.

Electronic Communications Privacy Act of 1986. 18 USC 2510 et seq., PL 99-508, Wash., DC, 10/21/86.

Escrowed Encryption Standard. U.S. Department of Commerce, National Technical Information Service (NTIS), FIPS PUB 185, Springfield, VA.

Everhart, Kathie, ed., Computer Security Training & Awareness Course Compendium. NIST, NISTIR 5495, Gaithersburg, MD., September 1994.

Executive Guide to ADP Contingency Planning. NIST, SP 500-85, Gaithersburg, MD., 1985.

FBI ADPT Security Policy. Department of Justice, Federal Bureau of Investigation, Information Systems Security Unit, National Security Division, Wash., DC, April 29, 1994.

Federal Computer Systems Security Training. HR 145-6, Section 5, House of Representatives, Wash., DC

Federal Information Resources Management Regulation (FIRMR). 40 CFR 201 et seq., Wash., DC.

Federal Managers Financial Integrity Act of 1982. (FMFIA) PL 97-255, H.R. 1526, 31 USC 1105, 1113, 3512, Wash., DC, September 1982.

Financial Management Systems. OMB Cir. A-127 (Revised), Transmittal Memorandum No. 1, Wash., DC, 07/23/93.

Glossary of Computer Security Terminology. National Security Telecommunications and Information Systems Security Committee (NSTISSC), Published by NIST as NISTIR 4659. Available from NTIS as PB92-112259, 1992.

Guidelines for ADP Contingency Planning. U.S. Department of Commerce, National Technical Information Service (NTIS), FIPS PUB 87, Springfield, VA., 03/81.

Guidance for Preparation of Security Plans for Federal Systems that Contain Sensitive Information. OMB Bulletin 90-08, Wash., DC, 07/09/90.

Guidelines for Writing Trusted Facility Manuals. NCSC, NCSC-TG-016, Ver.1, NSA, Ft. George G. Meade, MD., October 1992.

Information Technology Installation Security. GSA. Office of Technical Assistance. Wash., DC: GPO, December 1988.

Integrity - Oriented Control Objectives: Proposed Revisions to the Trusted Computer System Evaluation Criteria (TCSEC), DoD 5200.28-STD. NCSC, NCSC C TR 111-91, NSA, Ft. George G. Meade, MD., October 1991.

Issue Update On Information Security and Privacy in Network Environments. U.S. Congress. Office of Technical Assistance. OTA-BP-ITC-147. Wash., DC: GPO, June 1995.

Management Accountability and Control. OMB Cir. A-123. Wash., DC, June 21, 1995.

Office of the President, National Security Information. 32 CFR Part 2001, Directive No. 1, National Security Council, Information Security Oversight Office, Wash., DC, June 1982.

Office of the President, National Security Information: Standard Forms. 32 CFR Part 2003, National Security Council, Information Security Oversight Office, Wash., DC, March 1987.

The Paperwork Reduction Act of 1980. As amended. 44 USC 350, et seq., PL 96-511. Wash., DC, 12/11/80.

The Paperwork Reduction Reauthorization Act of 1986. 44 USC 3506, PL 99-500 Title VIII. Wash., DC.

Password Usage. U.S. Department of Commerce, National Technical Information Service (NTIS), FIPS PUB 112, Springfield, VA., May 1985.

People, Processes and Partnerships: A Report on the Customs Service for the 21st Century. U.S. Customs Service, Wash., DC, September 1994.

Performance of Commercial Activities. OMB Cir. A-76 (Revised), Transmittal Memorandum #13, Wash., DC, 03/02/94.

Personnel Suitability. Federal Personnel Manual (FPM) Instruction 311, Chapter 31, Wash., DC, 01/06/84.

Policy and Procedures Manual for Guidance of Federal Agencies -Title 2, Accounting. Government Accounting Office, Wash., DC, August 1987.

Public Key Encryption. NIST, SP 800-2, Gaithersburg, MD.

Requirements for a Shared Federal Computer Back-up Facility. Office of Technical Assistance, Falls Church, VA., May 1991.

Ruder, Brian, and J.D. Madden, An Analysis of Computer Security Safeguards for Detection and Prevention of Intentional Computer Misuse. NIST, SP 500-25, Gaithersburg, MD.

Ruthberg, Zella G. and William Nugent, Overview of Computer Security Certification and Accreditation. NIST, SP 500-109, Gaithersburg, MD., April 1984.

Smart Card Technology: New Methods for Computer Access Control. NIST, SP 500-157, Gaithersburg, MD.

Training Requirement for the Computer Security Act. Office of Personnel Management (OPM), 5 CFR PART 930, Federal Register Vol. 56, No. 233, Wash., DC, 12/04/91.

Trusted Database Management System Interpretation (TDI) of the Trusted Computer System Evaluation Criteria. NCSC, NCSC-TG-021, Ver. 1, NSA, Ft. George G. Meade, MD., April 1991.

Trusted Network Interpretation Environments Guideline. NCSC, NCSC-TG-011, Ver. 2, NSA, Ft. George G. Meade, MD., August 1990.

Trusted Product Evaluations: A Guide for Vendors. NCSC, NCSC-TG-002, Ver. 1, NSA, Ft. George G. Meade, MD., June 1990.

Turning Multiple Evaluation Products into Trusted Systems. NCSC, TR -003, NSA, Ft. George G. Meade, MD., July 1994.

U.S. Customs Service. Abbreviations and Acronyms. Wash., DC, 04/92.

U.S. Customs Service. Distribution, Submission and Processing of Background Investigation (BI) Forms. USCS Directive 099-51332-004, Wash., DC, 03/08/92.

U.S. Customs Service. Five Year Plan. Wash., DC, 12/91.

U.S. Customs Service. Information Systems Plan for Fiscal Years 1997 - 2001. Wash., DC, April 1995.

U.S. Customs Service. Personnel Security Requirements for ADP and Data Communications Contract Employees. USCS Directive 1400-12, Wash., DC, 11/02/88.

U.S. Customs Service. Physical Security Handbook. USCS HB 1400-02, Wash., DC, 08/89.

U.S. Customs Service. Prohibition of Unauthorized Use of Electronic Mail. USCS Directive 1460-008, Wash., DC, 11/25/91.

U.S. Customs Service. Restriction of Access to Production Data on the Customs Computer. USCS Information Notice 92-030, Wash., DC, 06/30/92.

U.S. Customs Service. Service Level Agreement. Office of Information Management, Springfield, VA., 09/30/92.

U.S. Customs Service. Table of Offenses and Penalties. USCS Directive 51751-01, Wash., DC, 01/09/90.

U.S. Customs Service. Unauthorized Release of Official Information. Commissioner Memorandum, Wash., DC, 07/08/91.

U.S. Customs Service. Use of Computer Virus Protection Software. USCS Directive 1400-26, Wash., DC, 05/01/91.

U.S. Customs Service. Use of Personally-Owned Computers and Software for Classified and Sensitive Work. USCS Directive 1460-011, Wash., DC, 03/25/93.

U.S. Treasury Department. Acquisition of Federal Information Processing Resources. TD 83-01, Wash., DC, 12/03/91.

U.S. Treasury Department. Disclosure of Records. 31 CFR Part 1, Subpart A - Freedom of Information and Reform Act (FOIA). PL 99-570. Wash., DC August 13, 1987.

U.S. Treasury Department. Electronic Funds and Securities Transfer Policy. Message Authentication and Enhanced Security. TD 16-02, Wash., DC, 12/21/92.

U.S. Treasury Department. Information Systems Planning. TD 81-06, Wash., DC, PL 99-570. 08/20/86.

U.S. Treasury Department. National Security Information. Treasury Directive. 31 CFR Part 2, Wash., DC, 2/22/89.

U.S. Treasury Department. Responsibilities for Telecommunications and Information Systems Security. TD 85-09, Wash., DC, 09/25/90.

Viability Study for a Shared Federal Computer Back-up Facility. Office of Technical Assistance, Falls Church, VA., November 1990.

Wack, John P., Establishing Computer Security Incident Response Capability (CSIRC). NIST, SP 800-3, Gaithersburg, MD., 1991.

Wack, John P. and Stanley A. Kutzban, Computer Virus Attacks. Computer Systems Laboratory (CSL) Bulletin, NIST Special, Gaithersburg, MD, August 1990.

APPENDIX A

Abbreviations and Acronyms

AA Accrediting Authority

ACS Automated Commercial System

ADP Automatic Data Processing

AES Automated Export System

AIS Automated Information Systems

AISS AIS Security Division

AS Administrative Systems

BI Background Investigation

CD-ROM Compact Disk-Read Only Memory

CFR Code of Federal Regulations

CIS Customs Issuance System

CICS Customer Information Control System

COMSEC Computer Security

COTS Commercial-Off-The-Shelf Software

CM Configuration Management

CMD Communications Management Division

CSC DoD Computer Security Center (now NCSC)

DAA Designated Accrediting Authority

DAC Discretionary Access Control

DES Data Encryption Standard

DOD Department of Defense (DoD)

DODD Department of Defense Directive

DSA Digital Signature Algorithm

DSO Designated Security Officer

DSS Digital Signature Standard

EO Executive Order

FBI Federal Bureau of Investigation

FEDSIM Federal Systems Integration and Management Center

FIPS PUB Federal Information Processing Standards Publication

FOIA Freedom of Information Act

GAO U.S. General Accounting Office

GPO U.S. Government Printing Office

GSA U.S. General Services Administration

HR House of Representatives Report

HB Handbook

IBM® International Business Machines

IRM Information Resources Management

IRS Internal Revenue Service

LAN Local Area Network

LOU Limited Official Use

MOU Memorandum of Understanding

MISSI Multilevel Information System Security Initiative

NBS National Bureau of Standards (now NIST)

NCIC National Crime Information Center

NCSC National Computer Security Center

NITF National Information Infrastructure Task Force

NIST National Institute of Standards and Technology

NSA National Security Agency

NSD National Security Directive

NSDD National Security Decision Directive

NTIS National Technical Information Service

NSTISS National Security Telecommunications and Information Systems Security

OIT Office of Information and Technology

OMB Office of Management and Budget

OPM Office of Personnel Management

OPS Systems Operations Division

ORR Office of Regulations and Rulings

OTA Office of Technical Assistance

PA Privacy Act

PAA Principal Accrediting Authority

PBX Private Branch Exchange

PC Personal Computer

PL Public Law

RAM Random Access Memory

ROM Read Only Memory

R/W Read/Write

SBU Sensitive But Unclassified

SDLC Systems Development Life Cycle

SFUG Security Features User's Guide

SP Special Publication

SPD Security Programs Division

TCB Trusted Computer Base

TCSEC DoD Trusted Computer System Evaluation Criteria (the Orange Book)

TECS Treasury Enforcement Communication Systems

TD Treasury Directive

TFM Trusted Facility Manual

UPS Uninterruptible Power Supply

USC United States Code

USCS U.S. Customs Service

WAN Wide Area Network

WWW World Wide Web

APPENDIX B

Good Security Practices

B.1 General Computer Care and Handling.

The owners or operators guides for computers and components specify special precautions, care, and handling procedures that can help avoid system failures and data loss.

The following are general guidelines and recommendations:

1. Plug each power cable into a grounded (3-hole) outlet. Use a good quality electrical surge protector, power filter system, or uninterruptible power supply to protect the computer system from electrical variations which can cause failures.

2. Do not connect or disconnect computer system components with the system turned on, unless the system and components are specifically designed for that purpose.

3. Electrostatic discharge (EDS) can cause computer component failures. Take precautions to discharge yourself before touching the computer or attached components. If you must work inside the computer, wear proper EDS grounding equipment (e.g., wrist straps, etc.) and frequently touch the unpainted metal chassis periodically to neutralize static buildup.

4. Keep strong magnetic fields away from the computer components and magnetic recording media (e.g., diskettes, tapes, etc.). If audio speakers are used with the system, ensure that they are designed with proper magnetic shielding.

5. Do not touch the surfaces of magnetic recording media (e.g., diskettes, tapes, etc.) or gold electrical connectors (circuit card contacts or connectors). Body oils will contaminate these surfaces and can result in component failures.

7. Protect computer equipment and recording media (e.g. portable PCS, diskettes, CDS, etc.) from adverse environmental conditions (e.g., extremes of temperature and humidity, corrosive gases, liquids, dust, or other contaminants).

6. Computer components do fail. Make appropriate back-ups of all critical data and store in a secure area, preferably separate from the same area where the computer is kept.

B.2 General Security Practices

1. Control physical access to computer systems and limit access to only authorized persons.

2. Position computer displays such that they may not be viewed by unauthorized persons (e.g., through windows, doors, open work areas, etc.).

3. Do not allow computer access by unauthorized persons:

Logoff active host or LAN connections whenever the terminal sessions are unattended.

Power off computer equipment when not in use.

Secure unattended terminal areas (lock the doors).

4. Identify the level of sensitivity of the data stored, processed, or used in the computer and implement appropriate security measures.

5. For systems which use logon IDs and/or password access controls, ensure that chosen IDs and/or passwords conform to the requirements of the specific control system where they are used.

Note: Passwords are a commonly used but easily compromised access control method. Automated computer penetration programs can quickly determine common words, names, or character combinations used for logon IDs and/or passwords. It is therefore prudent to make the ID and/or password as complex as appropriate.

(a) Change default passwords as soon as practical. Do not allow security access controls to be operational using manufacturer or vendor supplied passwords.

(b) Keep logon IDs confidential. Divulge IDs only on a need-to-know basis.

(d) Generally do not write down passwords. If it is necessary to write them down, store them in a secure area.

(e) Change passwords at least every 90 days (30 days is recommended) or any time they have been, or are suspected to have been, compromised.

(f) Do not include passwords in programs, scripts, or other files where they can be compromised.

(g) Recommended password patterns are:

- 6 to 8 alphanumeric characters, with at least one of each type (e.g., PQT1FYX).

- no sequentially repeated characters (e.g., 11, aa, etc.).

- no names, birthdays, commonly used identifiers (e.g., Social Security #, etc.).

- no ascending or descending digits (e.g., 1234, abcd, etc.).

6. Protect access control devices from loss or unauthorized access (e.g., lock keys, smart cards, Fortezza cards, encryption cards/keys, security codes, etc.).

Note: Loss or compromise of encryptions codes or devices (e.g., Fortezza cards, etc.) usually requires replacement of codes or devices at both sending and receiving locations. This can severely impact data availability. Protect all encryptions codes or devices.

7. Ensure proper control and disposal of printer ribbons, laser printer cartridges, recording media (e.g., diskettes, CDS, tapes, etc.), printouts, and other information storage devices which contain sensitive data.

8. Use adequate security controls to protect against malicious code:

Use a quality virus scanner and/or behavioral detection program.

Virus scanners only detect virus code patterns identified in the particular scanner.

Virus behavioral detection programs detect code pattern changes which are similar to those identified in the detection program.

Virus scanners and behavioral detection programs must be current (not more than 90-180 days old) to be effective. New virus programs are being created every month.

Any recorded media whose content is unknown or has not been scanned for known viruses, may be a source of malicious code contamination. Even new programs from established manufacturers and vendors have been sources of such contamination.

9. Information stored or processed by computers, related equipment, and programs can be damaged in numerous ways and from various causes. It is important that all data which is considered essential (e.g., programs, data files, etc.) be available and capable of being restored to the AIS environment, should the original become unusable. Back-up files should be created and maintained as appropriate. Security controls for the back-up files must be commensurate with the sensitivity and criticality of the data.

B.3 Good Security Practices for PBX and Voice Mail Systems

Dial-in access to sensitive AIS can be a serious security exposure if appropriate security controls are not operational. Most Private Branch Exchange and Voice mail systems have security features which can deter or prevent unauthorized access. It is important that these features be activated and enforced. The following recommendations are excerpts provided by American Telephone and Telegraph (ATT) to the U.S. Treasury Office of Telecommunications Management.

B.3.1 PBX Security

1. Keep PBX attendant console rooms, telephone wiring closets, telephone equipment rooms, and Local Exchange Company (LOC) demarcation rooms locked and secured.

2. Request positive identification from all service equipment vendors and technicians.

3. Ensure that any remote maintenance line phone number is unpublished, preferably not in the same numbers groups, and not recorded on jacks, wallfield, distribution frame, etc.

4. Secure any reports, documentation, or other information files which may reveal the trunk access codes or passwords.

5. Change all default passwords immediately after installation.

6. Choose passwords that are difficult, but easy to remember, and contain as many alpha characters/digits as possible, preferably seven or more.

7. Deactivate unused codes and features.

8. Allow only three attempts to enter a valid access code.

9. Have the PBX wait four or five rings before answering the remote access line.

10. Restrict calling privileges to individual employees.

11. Block area codes where business is not done, especially 900, 700, and 976.

12. Use the maximum authorization and Remote Access barrier code length.

13. Use security devices on all ports.

B.3.2 Voice Mail

1. Don't allow outgoing calls from a mailbox.

2. Set a minimum number of digits allowed for all passwords (preferably five or more).

3. Require a minimum password length to be one digit longer than extension length.

4. Block access to long distance trunks or local lines.

5. Require users to frequently change passwords.

6. Limit login attempts to three or less.

7. Toll restrict lines between the voice mail system and PBX.

8. Monitor voice mail system reports daily.

9. Delete all unused voice mailboxes.

10. If outcalling is used, restrict the port to only those numbers needed using the Automatic Route Selection partitioning.

APPENDIX C

Controlled Access Protection (C2) Outline

The National Policy on Controlled Access Protection, issued by the White House, National Telecommunications and Information Systems Security Committee, 07/15/87, directed that by July 15, 1992 Federal agencies must provide automated Controlled Access Protection (C2 level) for all sensitive or classified information processed or maintained by AIS, when all users do not have the same authorization to use the sensitive information. [NTISSP 200]

This outline highlights Treasury Security Manual, TD P 71-10, Chapter VI.4.B.1. on Controlled Access Protection (C2 level functionality), for AIS and networks processing Sensitive But Unclassified (SBU) Information. Exemption to these requirements require a formal Risk Assessment and approvals.

Functional Requirements

1. Controlled Access Protection (C2) must provide for the following:

Authentication.

Integrity.

Confidentiality.

Access Control.

Nonrepudiation.

Availability.

2. Protection is accomplished through:

Accountability (user identification/authentication).

Audit trail for relevant events.

Control of access requests.

Automatic clearing of residual data.

3. Protection is required for:

Mainframe systems

Networks running:

UNIX.

Multitasking multiuser Operating Systems.

Dial-up access to networks.

Networked DOS systems

Standalone Microprocessors.

If SBU is shared among systems then interim DAC required.

4. C2 level requirements include:

Identification based on User ID.

Authentication based on Password.

Audit based on an audit trail that includes:

Records for all events must include:

Date/time.

User ID.

Event type.

Success/failure.

Event records must be created and maintained, including:

Logon/logoff:

Origin of request (e.g., terminal ID).

Password change:

Origin of request (e.g., terminal ID).

File related events:

Name, create, delete, open, close.

Program initiation.

Actions by:

System operators.

Administrators.

Security officers.

Data access must be protected from modification by:

Limited Read access.

Reports must be:

Selective by user ID.

5. Discretionary Access Control (DAC) Requirements Summary:

Define/control access for:

Users.

Resources (e.g., files and programs).

Data access authorization:

User specifies access to data the own.

Unauthorized access denied.

6. Data Remanence Security Requirements Summary:

Magnetic media may require clearing.

Based on risk analysis.

Object Reuse:

Clearing, purging of data remanence.

7. Testing Requirement:

Assurance testing of C2 features must be formally conducted.

8. Documentation Requirements Summary:

Security Features User's Guide.

Trusted Facility Manual.

Test Documentation.

Design Documentation.

9. Security Products Analysis must include:

Documented review of product requirements/recommendations:

State areas of compliance.

Identify areas of noncompliance, including:

Corrective actions.

Formal exceptions.

10. Network Security Requirements:

Local Area Network Security (To Be Developed)

This section of the Treasury Security Manual is not available.

Dial-up Access Control.

Explicit ID, authentication, and audit trail.

If encrypted, then must comply with TD P 71-10, VI.3.A.

When SBU data is transmitted using NSA Type II encryption:

It must use the Data Encryption Standard (DES).

Note: Encryption is not mandatory, but can be a cost-effective risk-management consideration.

(This Page Intentionally Left Blank)

APPENDIX D

Security Plan Format

Security Plan Elements

There is no fixed format for a security plan, however the plan should include the following basic elements.

1. System Identification

Responsible Organization

System Name/Title

System Category

System Operational Status

General Description/Purpose

System Environment and Special Considerations

Information Contact(s)

2. Information Sensitivity type:

Public/Unclassified

Sensitive But Unclassified

Several categories

3. Security Measures taken:

Physical control

Hardware control

Software controls

Administrative controls

Access Control

Data protection

Communication protection

Etc.

The following model is from the Customs Systems Development Life Cycle manual, CIS HB 5500-04, 1996, and is an acceptable format guideline.

SECURITY PLAN

Project Name: Project Number:

Date Prepared: __/__/__ Date Updated: __/__/__ Date Presented __/__/__ Date Approved __/__/__

INITIATION PHASE

1. System Identification - This section contains basic identifying information about the system.

A. Responsible Organization

B. System Name/Title

C. System Category - State whether it is a Major application, General support system, etc.

D. System Operational Status - State whether it is Operational, Under development, Undergoing a major modification or a significant security change

E. General Description/Purpose

F. System Environment and Special Considerations

G. Information Contact(s)

DEFINITION STAGE

2. Sensitivity of Information - Identify the types of information to be processed. For each type of information, identify the following:

A. Applicable Laws or Regulations

B. Whether the integrity protection requirement is low, medium, or high

C. Whether the availability protection required is low, medium, or high

D. Whether the confidentiality protection required is low, medium, or high

DEFINITION STAGE

3. System Security Measures - This section should describe the control measures (in place or planned) that are intended to meet the protection requirements of the system. The types of control measures should be consistent with the need for protection of the system described in the previous section.

A. Risk Assessment and Management

B. Applicable Guidance

C. Security Control Measures - For each control measure (categories 1-6 below), specify whether it is inplace, planned, not applicable with "Security Control Measures - Describe the Control Measures"

1. Management Controls - Overall management controls of the system.

a. Assignment of Security Responsibility

b. Risk Analysis

c. Personnel Screening

2. Acquisition/Development/Installation/Implementation Controls - Procedures to assure protection is built into the system, especially during system development.

a. Acquisition/Security Specifications

b. Configuration Management

c. Quality Assurance

d. Design Review and Testing

e. Accreditation/Certification

3. Operational Controls - Day-to-day procedures and mechanisms to protect systems when they become operational.

a. Physical and Environmental Protection

b. Production, I/O Controls

c. Emergency, Back-up, and Contingency Planning

d. Audit and Variance Detection

e. Hardware and System Software Maintenance Controls

f. Documentation

g. Configuration Management

h. Security Administration

i. Database Administration

4. Security Awareness and Training - Security awareness and training of users, technical staff, and managers concerning the system.

a. Security Awareness and Training Measures

5. Technical Controls - Hardware and software controls used to provide automated and/or facilitate manual protections.

a. User Identification and Authentication

b. Authorization/Access Controls

c. Integrity/Validation Controls

d. Audit Trails

e. Confidentiality Controls

6. Controls Over the Security of Applications (including controls provided by Support Systems) -

The security of each application that processes on a support system affects the security of all others processing there. The manager of the support system should understand the risk that each application represents to the system.

4. Additional Comments - This final section is intended to provide an opportunity to include additional comments about the security of the subject system and any perceived need for guidance or standards.

(This Page Intentionally Left Blank)

APPENDIX E

Computer Security Training

1. INTRODUCTION

The Office of Personnel Management (OPM) has issued training regulations which implement the Computer Security Act of 1987 by prescribing the general procedures, scope, and manner of security training to be provided to Federal civilian employees.

2. AUTHORITY

The Computer Security Act of 1987, PL 100-235, was enacted to improve the security and privacy of sensitive information in Federal computer systems. As one way of meeting that goal, the law requires that each agency shall provide for the mandatory periodic training in computer security awareness and accepted computer practices of all employees who are involved with the management, use, or operation of each computer system within or under the supervision of the agency.

The National Institute of Standards and Technology (NIST) Special Publication No. 500-172,. Computer Security Training Guidelines, 11/89, sets the specific guidelines for development and implementation of required awareness training and reporting.

3. ORGANIZATION RESPONSIBILITIES

(Reference: TD P 71-10, VI.8.A, 1992).

Director, Office of Security (DOS): U.S. Treasury

- Manage training and awareness programs.

- Coordinate training and awareness programs.

- Review agency training and awareness programs for compliance.

Deputy Assistant Secretary, Information Systems (DASIS): U.S. Treasury

- Develop and review training and awareness guidelines.

- Review agency training and awareness programs for compliance.

Heads of Bureaus:

- Develop, fund, and implement training and awareness program.

- Ensure contractors are trained (required contract provisions).

- Appoint bureau official as liaison to annually (July 31) report training and awareness program status to DOS (Treasury).

- Annually develop, maintain, and update training and awareness program.

- Annually report training status and plans summary to DOS.

4. AWARENESS TRAINING BASIC REQUIREMENTS

Computer Security Training Guidelines, 11/89. [NIST 500-172]

4.1. Objectives:

a. Understand the value of information.

b. Awareness of vulnerabilities, risks, and threats to AIS.

c. Understanding to enable personnel to apply Federal, Treasury, and Bureau INFOSEC/COMSEC policies, practices, and procedures.

4.2. Procedures:

a. New personnel within 5-days of appointment.

- Orientation on specific responsibilities.

- Managers, users, or operators using SBU data, within 60-days.

b. Training update whenever AIS INFOSEC/COMSEC environment changes.

c. Threat briefing and awareness refresher. All personnel. OMB Circular A-130, February 8, 1996 requires that security awareness training must be periodic. The NIST Computer Security Training Guidelines, 11/89 recommend annual refresher training, but it is not a requirement. [NIST 500-172]

Examples of training: e-Mail, newsletter, memoranda, training diskettes, videos.

4.3. Content/Audience:

a. Minimum content/subject matter:

- Security basics, security planning and management.

- May use in-house or commercial training.

b. Must include bureau and contractor personnel for each content area:

- executives, operations, programming staff, and users.

c. Training level for each specific target audience category, based on individual responsibilities, should include:

- awareness, policy, implementation, and performance.

4.4. Reporting:

a. Bureau Head reports to DOS by 07/31 annually.

- Name, phone, address of agency training liaison.

b. Prior 12 month training summary.

c. Projected course of study for next fiscal year.

- Approximate number of jobs (billets) involved.

- Areas of study.

- Audience type (e.g., technical, management, etc.).

5. COMPUTER SECURITY BASICS TOPICAL OUTLINE

5.1. Threats and Vulnerabilities

- Definitions of terms

- Major threats:

- Unauthorized, accidental, or intentional;

- disclosure;

- modification;

- destruction; and

- delay.

- Impact areas.

- Computer abuse examples.

- Vulnerability examples.

5.2. Organizational responsibilities

- Policy makers.

- Senior management.

- End users, programmers, or Functional managers.

- Data Processing organization.

- Information Resources Management, Security, and Audit functions.

5.3. Risk management basic concepts

- Threat and vulnerability assessment.

- Cost/benefit analysis.

- Cost-effective controls.

- Efficiency/effectiveness of controls.

5.4. Policy for protecting information

- Agency computer security policy.

- Employee/contractor accountability for information resources.

5.5. Good security practices

- Physical/electronic protection of:

- physical areas (spaces);

- equipment;

- passwords;

- data files;

- against viruses, worms, etc.;

- back-up of data files;

- storage of magnetic media; and

- reporting security violations.

6. BASIC LEVEL: COMPUTER SECURITY AWARENESS TRAINING

6.1. Threats and Vulnerabilities

- Definitions of terms.

- Sources of threats:

- External:

- Things outside the computer systems,

- facilities,

- environment,

- physical controls, and

- physical emergencies, etc.

- Supervisor Mode:

- Things inside the computer systems:

- hardware,

- firmware, and

- operating software.

- User Mode:

- Things users interface to the computer systems:

- application software,

- user software,

- utility software, and

- communications, etc.

- Object of Threats:

- Operating System and Subsystem Integrity,

- Accounting mechanisms,

- User validation,

- Priority and process scheduling,

- Integrity of code,

- Memory access control, and

- Continuity of operations.

- Data Set Access Control:

- Read,

- Write,

- Execute,

- Append,

- Delete,

- Restrict access to specific programs, and

- Control of offline files (tape, disk, etc.).

- Major threats:

- Unauthorized, accidental, or intentional,

- disclosure,

- modification,

- destruction, and

- delay.

- Impact areas:

- Computer abuse examples, and

- Vulnerability examples.

6.2. Organizational responsibilities

- Policy makers:

- Senior management;

- End users, programmers, or Functional managers;

- Data Processing organization; and

- Information Resources Management, Security, and Audit functions.

6.3. Risk management basic concepts

- Threat and vulnerability assessment,

- Cost/benefit analysis,

- Cost-effective controls, and

- efficiency/effectiveness of controls.

6.4. Policy for protecting information

- Agency computer security policy,

- Employee/contractor accountability for information resources.

6.5. Good security practices

- Physical/electronic protection of:

- areas,

- equipment,

- passwords,

- data files,

- against viruses, worms, etc.,

- back-up of data files,

- storage of magnetic media, and

- reporting security violations.

(This Page Intentionally Left Blank)

APPENDIX F

Security Requirements Methodology

SECURITY POLICY

[TD P 71-10; USCS 96PLAN]

The U.S. Treasury Department designates Customs as a Category I agency whose essential functions are uninterruptible and critical to the continuity of the Federal government.

Customs mission includes:

(a) Ensure that all goods and persons entering or exiting the United States do so in compliance with all the United States laws and regulation.

(b) Protect the public against violations which threaten the national economy and health and safety.

These activities provide active enforcement of U.S. laws, including the control and generation of significant financial revenue to the U.S. Treasury.

Customs general support AISs and major AIS applications that create, collect, communicate, compute, disseminate, store, and/or control data which includes law enforcement, personal, financial, and counternarcotics information are assigned the security category of Sensitive But Unclassified (SBU). SBU information must be protected in a manner functionally equivalent to the DoD classification level of C2.

OPERATIONAL SECURITY POLICY

Customs operational security policy specifies the critical aspects of Customs AISs and the manner in which regulatory policy is to be satisfied. It includes the tradeoff decisions made between various security safeguards and involves the functional allocation of the various security-related tasks to the elements of the AISs. The tradeoffs of cost, performance, and risk help determine how security will be built and implemented.

ANALYSIS AND DESIGN OF AIS

The analysis of existing AISs and the design of evolving or new ones generally proceeds from the regulating policy(ies) to the mechanisms implementing compliance to those policies. There are many ways to satisfy security requirements and policy is frequently subject to change to accommodate changes in technology, environment, political and organization structure, and regulations of various kinds. It is therefore important that any analysis or design consider current requirements.

INTERFACE POLICY

The exchange of between AISs is based on explicit interface policy and can be thought of as an augmentation of importing and exporting of data. Such exchange must consider that: 1) the data sent must continue to be protected at the owner assigned level of control, and 2) the data received must continue to be protected at the owner assigned level of control.

In most cases, Customs data must be controlled at security functional level equivalent to C2. It is the responsibility of the sending AIS to assure that any virtual communications channels, and/or receiving AIS, provide appropriate protection controls.

TRUSTED COMPUTER BASE (TCB) POLICY

The Trusted Computer Base (TCB) concept provides a sound method of AIS security evaluation.

Evaluations of mechanisms which are shared by TCBs must be done individually to ensure consistency with interface policy and discretionary access controls (DAC). Each TCB must provide for a security administrator and generate relevant audit records.

Networked TCBs must be reviewed to consider the implications of failure on one of the component TCBs from the standpoint of its impact to all of the interconnecting entities. A means to cooperatively shut down and recover in a secure manner must exist.

RISK MANAGEMENT POLICY

A TCB which has not been assured to comply with the security considerations should be considered and treated as a risk. A small part of the risk management process is the risk assessment procedure. Considering the results of risk assessment, the risk management may require an iteration of operational policy to ensure compliance to regulatory policy.

Propagated risk results from the risk level of one AIS cascading to another interconnected AIS. The inherent risk of one AIS may increase the exposed risk of another AIS when interconnection does not limit related risks. It is possible that interconnections of AISs can result in a combined contributed risk greater than that solely contributed by any single AIS. The four risk factors (risk index, exposed risk, contributed risk, and solely contributed risk) must be considered when evaluating an AIS. [TD 85-03]

In many situations the security goals can be achieved without redesign of existing AISs, also evolving and new systems can generally add more function and capability while realizing security goals. The risk management approach is also a major step towards achieving the security recommended for networked AISs.

APPENDIX G

OMB Circulars

OMB Circular No. A-123, Introduction & Comments

OFFICE OF MANAGEMENT AND BUDGET

Management Accountability and Control

AGENCY: Office of Management and Budget

ACTION: Final Revision of OMB Circular No. A-123

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

SUMMARY: This Notice revises Office of Management and Budget (OMB) Circular No. A-123, "Management Accountability and Control." The Circular, which was previously titled "Internal Control Systems," implements the Federal Managers' Financial Integrity Act of 1982 (FMFIA).

FOR FURTHER INFORMATION CONTACT: Office of Management and Budget, Office of Federal Financial Management, Management Integrity Branch, Room 6025, New Executive Office Building, Washington, D.C. 20503, telephone (202) 395-6911 and fax (202) 395-3952. For a copy of the revised Circular, contact Office of Administration, Publications Office, Room 2200, New Executive Office Building, Washington, D.C. 20503, or telephone (202) 395-7332.

ELECTRONIC ACCESS: This Circular is also accessible on the U.S. Department of Commerce's FedWorld Network under the OMB Library of Files.

The Telnet address for FedWorld via Internet is "fedworld.gov".

The World Wide Web address is "http://www.fedworld.gov/ftp.htm#omb".

For file transfer protocol (FTP) access, the address is "ftp://fwux.fedworld.gov/pub/omb/omb.htm".

The telephone number for the FedWorld help desk is (703) 487-4608.

SUPPLEMENTARY INFORMATION:

A. Background

Circular No. A-123 was last issued on August 4, 1986. On March 13, 1995 the Office of Management and Budget requested public comments on a revised version of the Circular (60 FR 13484).

The revision announced here alters requirements for executive agencies on evaluating management controls, consistent with recommendations made by the National Performance Review. The Circular now integrates many policy issuances on management control into a single document, and provides a framework for integrating management control assessments with other work now being performed by agency managers, auditors and evaluators.

The Circular emphasizes that management controls should benefit rather than encumber management, and should make sense for each agency's operating structure and environment. By giving agencies the discretion to determine which tools to use in arriving at the annual assurance statement to the President and the Congress, the Circular represents an important step toward a streamlined management control program that incorporates the reinvention principles of this Administration.

B. Analysis of Comments

Thirty-three responses were received from 23 Federal agencies and the American Institute of Certified Public Accountants (AICPA). Of the 33 responses, 14 simply agreed with the proposed revision and made no comments on the document, although some had minor comments on a proposal by the Chief Financial Officers' Council to streamline reporting. Almost all of the remaining 19 responses were also in favor of the revision, but made some specific suggestions.

A summary of the transmittal memorandum and the five sections of the Circular follows. Each section indicates which comments were accepted and which were not accepted.

Transmittal Memorandum. This memorandum, signed by the OMB Director, summarizes the purpose, authority, and policy reflected in the Circular, the actions required, and related administrative information. Four agencies made comments relating to the memorandum.

Comments Accepted: The statement describing management accountability is now repeated in Section I of the Circular. The definition of management controls (which appears in both the memorandum and Section II) has been amended to state that controls should ensure reliable "and timely" information. The requirement that agencies report annually on management controls is now explicitly stated in the memorandum. In addition, OMB has added instructions on accessing the Circular electronically.

Comment Not Accepted: One agency suggested that performance appraisals be used to hold managers accountable for management control responsibilities. OMB supports this concept but prefers that the specific content of appraisals be left to each agency.

Section I. Introduction. This section describes a framework for agency management control programs that integrates management control activities with other management requirements and policies, such as the Government Performance and Results Act (GPRA), the Chief Financial Officers (CFOs) Act, the Inspector General (IG) Act, and other congressional and Executive Branch requirements. The foundation of this policy is that management control activities are not stand-alone management practices, but rather are woven into the day-to-day operational responsibilities of agency managers.

Agencies are encouraged to plan for how the requirements of the Circular will be implemented. Agencies are also encouraged to establish senior level management councils to address management accountability and related issues within the broad context of agency operations.

Comments Accepted: At the suggestion of three agencies, the language illustrating how controls can be integrated into the overall management process has been clarified. The text now indicates more clearly that the examples used to make this point are in fact examples, not new Circular requirements. Because the Act encompasses agency operations, as well as program and administrative areas, appropriate language has been included in the Circular. In addition, the Circular states that 24 agencies are covered by the CFOs Act, which reflects the legislation last year that made the Social Security Administration an independent agency from the Department of Health and Human Services.

Comments Not Accepted: Two agencies questioned elimination of the Management Control Plan. The importance of planning has not been diminished in the new Circular, but OMB will no longer dictate the scope and content of an agency's planning document. An agency may choose, for example, to meet the Circular's planning requirement by addressing management controls in a broader strategic plan for agency management.

Section II. Establishing Management Controls. This section defines management controls, and requires agency managers to develop and implement appropriate management controls. Included in this section are general and specific management control standards, drawn in large part from the standards issued by the General Accounting Office (GAO). By including these standards in the Circular, OMB is continuing its efforts to integrate various management control policies into a single document to make it easier for Federal managers to implement good management controls.

Comments Accepted: Four agencies questioned whether the definition of internal controls as a subset of management controls should be limited to conditions "that could have a material effect on [the entity's] financial statements." One agency pointed out that deficiencies in internal controls related to events that have less than a major impact on financial statements, like security weaknesses or conflict of interest problems, could be reportable under the Integrity Act. OMB agrees and has deleted the restrictive phrase.

In response to one agency's comment, language on developing management controls has been expanded to emphasize that controls must be developed as programs are initially implemented, as well as reengineered. At another agency's suggestion, a statement has been included on the value of drawing on the expertise of the CFO and IG as controls are developed.

Responding to two agencies' comments on the standards for management controls, the standard on compliance with law has been expanded to included compliance with regulations, and the standard on delegation of authority now clearly states that managers should ensure that authority, responsibility and accountability are defined and delegated.

Comments Not Accepted: The AICPA recommended that the Circular adopt the framework and definitions of internal controls developed by the Committee of Sponsoring Organizations of the Treadway Commission (the COSO framework). OMB has carefully reviewed the COSO approach and feels confident that the Circular incorporates virtually all of the concepts underlying the COSO framework. It is critical, however, for the Circular to present these concepts in language that is meaningful to Federal program managers as well as financial managers. Therefore, OMB has decided to retain the Circular's broader terminology.

One agency questioned OMB's authority to (i) include management control standards in the Circular and (ii) modify the language of GAO's Standards for Internal Control. OMB has included GAO in discussions about the Circular's revision since the beginning of the effort, and has provided GAO with the opportunity to comment on numerous drafts of the document. GAO has not objected to inclusion of the standards in the Circular, nor has GAO questioned the document's specific language. OMB believes that the Circular accurately incorporates the GAO standards, and appropriately updates the language to reflect developments in this area since GAO issued its standards in 1983.

Two agencies recommended more flexibility in the standard relating to separation of duties, arguing that the principle may be overly rigid in an era of downsizing. One agency described the difficulty of applying this standard in small field offices, and suggested that alternative controls based on advanced technology, such as systems access controls and automated audit trails, may be appropriate. While OMB believes that separation of duties is a key management control standard, it recognizes the validity of these examples. The standard has not been modified because appropriate flexibility is already provided; the language states that key duties "should" be separated among individuals.

One agency questioned whether the Circular adequately emphasizes the concept of reasonable assurance. OMB recognizes the importance of this concept, and believes that its inclusion as one of the general management control standards is sufficient.

Section III. Assessing and Improving Management Controls. This section states that agency managers should continuously monitor and improve the effectiveness of management controls. This continuous monitoring, and other periodic evaluations, should provide the basis for the agency head's annual assessment of and report on management controls. Agencies are encouraged to use a variety of information sources to arrive at the annual assurance statement to the President and the Congress. Several examples of sources of information are included in this section. The role of the agency's senior management council in making recommendations on the annual assurance statement and on which deficiencies in management controls should be considered material is also addressed.

Comments Accepted: OMB recognizes the need to clarify how the term "material weakness" as used in the Circular differs from the same term as used by Federal auditors. This issue was raised by one agency in its written comments, and by other parties in discussions of earlier drafts. The Circular now recognizes that Federal auditors are required to identify and report weaknesses that, in their opinion, pose a risk or threat to the internal control systems of an entity (such as a program or operation) even if the management of that entity would not report the weakness outside the agency.

Comments Not Accepted: Two agencies found the Circular's requirements on assessing and documenting the sufficiency of management controls to be inadequate, and suggested that the Circular provide more specific guidance in these areas. In keeping with the philosophy behind the Circular, OMB prefers to give agencies the latitude to expand upon the Circular's requirements in these areas, if they believe it is necessary, rather than to impose uniform criteria for determining, for example, what should be reported as a material weakness.

Along those lines, OMB has chosen not to adopt the definitions used by Federal auditors of a reportable condition and material weakness, as advocated by one agency and the AICPA. Those definitions are weighted heavily toward technical, financially-oriented terms that are probably not meaningful to Federal program managers. They also focus on financial statements as the primary end-product of an internal control structure. While financial statements are important tools for the agency head in arriving at an assurance statement on management controls, they are not the only source of information for making this determination. Therefore, it is important that the Circular use language that accurately reflects the broad nature of agency management controls.

Two agencies felt that the Circular should require that agencies test their management controls. OMB agrees that testing is an important method for determining whether controls actually work, and encourages agencies to use some form of testing. Because testing is already implicit in several of the information sources to be used to assess controls, and is less feasible for other information sources, it is not included as a blanket requirement.

Three agencies commented on the composition of an agency's senior management council; two felt that the Circular should be more specific in discussing membership, while one found this section too prescriptive. OMB believes that the current language adequately addresses the importance of including both line and staff management and involving the IG, without infringing on the agency's ability to determine the council's membership.

Section IV. Correcting Management Control Deficiencies. This section states that agency management is responsible for taking timely and effective action to correct management control deficiencies. Correcting these deficiencies is an integral part of management's responsibilities and must be considered a priority by the agency.

The only comment received on this section reflected a misunderstanding of the Circular's requirements on corrective action plans. Plans must be developed, tracked, and reported for all material weaknesses (weaknesses included in the Integrity Act report). For weaknesses that are not included in the report, plans should be developed and tracked at a level deemed appropriate by the agency.

Section V. Reporting on Management Controls. This section describes the required components of the agency's annual Integrity Act report and its distribution to the President and the Congress. This section also describes an initiative to streamline reporting by consolidating Integrity Act information with other performance-related reporting into a broader "Accountability Report" to be issued annually by the agency head. Lastly, this section presents Integrity Act requirements as they pertain to government corporations pursuant to the CFOs Act.

Comments Accepted: At the suggestion of two commenters, agencies are now encouraged to make their Integrity Act reports available electronically. The reference to a House committee has been changed to reflect the nomenclature of the 104th Congress.

This section also describes an new approach towards financial management reporting that could help integrate management initiatives. This approach is being pilot-tested by several agencies for FY 1995. Further information on the implications of this initiative for other agencies will be issued by OMB after the pilot reports have been evaluated.

Comments Not Accepted: One agency questioned the wisdom of permitting agencies to provide a qualified statement of assurance. OMB expects agencies to provide the most direct possible statement of assurance. The option of a qualified statement recognizes that in some cases, the most accurate statement of assurance is one that is qualified by exceptions that are explicitly noted.

The same agency suggested new language in the reporting section to recognize that the Circular broadens the scope of internal control accountability beyond the requirements of the Integrity Act. OMB disagrees with the premise that the link between management controls and program performance is a new one. While the Integrity Act uses financially oriented terminology, the Act "clearly encompasses program and administrative areas, as well as the more traditional accounting and financial management areas" (House Report 98-937, "First-Year Implementation of the Federal Managers' Financial Integrity Act," Committee on Government Operations, August 2, 1984, p. 1).

General Issues. Some comments were not limited to specific sections of the Circular.

Comments Accepted: In response to one agency's suggestion, the acronym "FMFIA" has been replaced throughout the Circular by the term "Integrity Act" to better emphasize the purpose and scope of the law. OMB has also modified the term "should" in several instances where specific agency action is required.

Comments Not Accepted: Two agencies proposed that the Circular broaden the linkage between management controls and other management initiatives, particularly performance measurement and implementation of GPRA. OMB encourages agencies to integrate their efforts to evaluate management controls and program performance, but is not prepared at this time to include policy guidance on performance measurement in this Circular.

One agency proposed inclusion of language describing the applicability of the Circular to discretionary policy matters, as had been done in the 1986 version. OMB does not believe that this language is necessarybecause it is clear that the President and agency head have full discretion over policymaking functions, including determining and interpreting policy, determining program need, making resource allocation decisions, and pursuing rulemaking.

Two agencies suggested that the Circular specifically address OMB's High Risk Program. OMB has chosen not to do so because implementation of the management control program outlined in the Circular will likely eliminate the need for separate tracking of high risk areas. If agencies report their most serious management deficiencies to the President and the Congress as envisioned by the Circular, the Integrity Act reports will essentially reflect the highest risk areas in government, and a separate High Risk Program may no longer be necessary.

(Signed)

John B. Arthur,

Associate Director for Administration

Circular No. A-123, Revised

June 21, 1995

TO THE HEADS OF EXECUTIVE DEPARTMENTS AND ESTABLISHMENTS

FROM: Alice M. Rivlin

Director

SUBJECT: Management Accountability and Control

1. Purpose and Authority. As Federal employees develop and implement strategies for reengineering agency programs and operations, they should design management structures that help ensure accountability for results, and include appropriate, cost-effective controls. This Circular provides guidance to Federal managers on improving the accountability and effectiveness of Federal programs and operations by establishing, assessing, correcting, and reporting on management controls.

The Circular is issued under the authority of the Federal Managers' Financial Integrity Act of 1982 as codified in 31 U.S.C. 3512.

The Circular replaces Circular No. A-123, "Internal Control Systems," revised, dated August 4, 1986, and OMB's 1982 "Internal Controls Guidelines" and associated "Questions and Answers" document, which are hereby rescinded.

2. Policy. Management accountability is the expectation that managers are responsible for the quality and timeliness of program performance, increasing productivity, controlling costs and mitigating adverse aspects of agency operations, and assuring that programs are managed with integrity and in compliance with applicable law.

Management controls are the organization, policies, and procedures used to reasonably ensure that (i) programs achieve their intended results; (ii) resources are used consistent with agency mission; (iii) programs and resources are protected from waste, fraud, and mismanagement; (iv) laws and regulations are followed; and (v) reliable and timely information is obtained, maintained, reported and used for decision making.

3. Actions Required. Agencies and individual Federal managers must take systematic and proactive measures to (i) develop and implement appropriate, cost-effective management controls for results-oriented management; (ii) assess the adequacy of management controls in Federal programs and operations; (iii) identify needed improvements; (iv) take corresponding corrective action; and (v) report annually on management controls.

4. Effective Date. This Circular is effective upon issuance.

5. Inquiries. Further information concerning this Circular may be obtained from the Management Integrity Branch, Office of Federal Financial Management, Office of Management and Budget, Washington, DC 20503, 202/395-6911.

6. Copies. Copies of this Circular may be obtained by telephoning the Executive Office of the President, Publication Services, at 202/395-7332.

7. Electronic Access. This document is also accessible on the U.S. Department of Commerce's FedWorld Network under the OMB Library of Files.

The Telnet address for FedWorld via Internet is "fedworld.gov".

The World Wide Web address is "http://www.fedworld.gov/ftp.htm#omb".

For file transfer protocol (FTP) access, the address is "ftp://fwux.fedworld.gov/pub/omb/omb.htm".

The telephone number for the FedWorld help desk is 703/487-4608.

Attachment

I. INTRODUCTION

The proper stewardship of Federal resources is a fundamental responsibility of agency managers and staff. Federal employees must ensure that government resources are used efficiently and effectively to achieve intended program results. Resources must be used consistent with agency mission, in compliance with law and regulation, and with minimal potential for waste, fraud, and mismanagement.

To support results-oriented management, the Government Performance and Results Act (GPRA, P.L. 103-62) requires agencies to develop strategic plans, set performance goals, and report annually on actual performance compared to goals. As the Federal government implements this legislation, these plans and goals should be integrated into (i) the budget process, (ii) the operational management of agencies and programs, and (iii) accountability reporting to the public on performance results, and on the integrity, efficiency, and effectiveness with which they are achieved.

Management accountability is the expectation that managers are responsible for the quality and timeliness of program performance, increasing productivity, controlling costs and mitigating adverse aspects of agency operations, and assuring that programs are managed with integrity and in compliance with applicable law.

Management controls -- organization, policies, and procedures -- are tools to help program and financial managers achieve results and safeguard the integrity of their programs. This Circular provides guidance on using the range of tools at the disposal of agency managers to achieve desired program results and meet the requirements of the Federal Managers' Financial Integrity Act (FMFIA, referred to as the Integrity Act throughout this document).

Framework. The importance of management controls is addressed, both explicitly and implicitly, in many statutes and executive documents. The Federal Managers' Financial Integrity Act (P.L. 97-255) establishes specific requirements with regard to management controls. The agency head must establish controls that reasonably ensure that: (i) obligations and costs comply with applicable law; (ii) assets are safeguarded against waste, loss, unauthorized use or misappropriation; and (iii) revenues and expenditures are properly recorded and accounted for. 31 U.S.C. 3512(c)(1). In addition, the agency head annually must evaluate and report on the control and financial systems that protect the integrity of Federal programs. 31 U.S.C. 3512(d)(2). The Act encompasses program, operational, and administrative areas as well as accounting and financial management.

Instead of considering controls as an isolated management tool, agencies should integrate their efforts to meet the requirements of the Integrity Act with other efforts to improve effectiveness and accountability. Thus, management controls should be an integral part of the entire cycle of planning, budgeting, management, accounting, and auditing. They should support the effectiveness and the integrity of every step of the process and provide continual feedback to management.

For instance, good management controls can assure that performance measures are complete and accurate. As another example, the management control standard of organization would align staff and authority with the program responsibilities to be carried out, improving both effectiveness and accountability. Similarly, accountability for resources could be improved by more closely aligning budget accounts with programs andcharging them with all significant resources used to produce the program's outputs and outcomes.

Meeting the requirements of the Chief Financial Officers Act (P.L. 101-576, as amended) should help agencies both establish and evaluate management controls. The Act requires the preparation and audit of financial statements for 24 Federal agencies. 31 U.S.C. 901(b), 3515. In this process, auditors report on internal controls and compliance with laws and regulations. Therefore, the agencies covered by the Act have a clear opportunity both to improve controls over their financial activities, and to evaluate the controls that are in place.

The Inspector General Act (P.L. 95-452, as amended) provides for independent reviews of agency programs and operations. Offices of Inspectors General (OIGs) and other external audit organizations frequently cite specific deficiencies in management controls and recommend opportunities for improvements. Agency managers, who are required by the Act to follow up on audit recommendations, should use these reviews to identify and correct problems resulting from inadequate, excessive, or poorly designed controls, and to build appropriate controls into new programs.

Federal managers must carefully consider the appropriate balance of controls in their programs and operations. Fulfilling requirements to eliminate regulations ("Elimination of One-Half of Executive Branch Internal Regulations," Executive Order 12861) should reinforce to agency managers that too many controls can result in inefficient and ineffective government, and therefore that they must ensure an appropriate balance between too many controls and too few controls. Managers should benefit from controls, not be encumbered by them.

Agency Implementation. Appropriate management controls should be integrated into each system established by agency management to direct and guide its operations. A separate management control process need not be instituted, particularly if its sole purpose is to satisfy the Integrity Act's reporting requirements.

Agencies need to plan for how the requirements of this Circular will be implemented. Developing a written strategy for internal agency use may help ensure that appropriate action is taken throughout the year to meet the objectives of the Integrity Act. The absence of such a strategy may itself be a serious management control deficiency.

Identifying and implementing the specific procedures necessary to ensure good management controls, and determining how to evaluate the effectiveness of those controls, is left to the discretion of the agency head. However, agencies should implement and evaluate controls without creating unnecessary processes, consistent with recommendations made by the National Performance Review.

The President's Management Council, composed of the major agencies' chief operating officers, has been established to foster governmentwide management changes ("Implementing Management Reform in the Executive Branch," October 1, 1993). Many agencies are establishing their own senior management council, often chaired by the agency's chief operating officer, to address management accountability and related issues within the broader context of agency operations. Relevant issues for such a council include ensuring the agency's commitment to an appropriate system of management controls; recommending to the agency head which control deficiencies are sufficiently serious to report in the annual Integrity Act report; and providing input for the level and priority of resource needs to correct these deficiencies. (See also Section III of this Circular.)

II. ESTABLISHING MANAGEMENT CONTROLS

Definition of Management Controls. Management controls are the organization, policies, and procedures used by agencies to reasonably ensure that (i) programs achieve their intended results; (ii) resources are used consistent with agency mission; (iii) programs and resources are protected from waste, fraud, and mismanagement; (iv) laws and regulations are followed; and (v) reliable and timely information is obtained, maintained, reported and used for decision making.

Management controls, in the broadest sense, include the plan of organization, methods and procedures adopted by management to ensure that its goals are met. Management controls include processes for planning, organizing, directing, and controlling program operations. A subset of management controls are the internal controls used to assure that there is prevention or timely detection of unauthorized acquisition, use, or disposition of the entity's assets.

Developing Management Controls. As Federal employees develop and execute strategies for implementing or reengineering agency programs and operations, they should design management structures that help ensure accountability for results. As part of this process, agencies and individual Federal managers must take systematic and proactive measures to develop and implement appropriate, cost-effective management controls. The expertise of the agency CFO and IG can be valuable in developing appropriate controls.

Management controls guarantee neither the success of agency programs, nor the absence of waste, fraud, and mismanagement, but they are a means of managing the risk associated with Federal programs and operations. To help ensure that controls are appropriate and cost-effective, agencies should consider the extent and cost of controls relative to the importance and risk associated with a given program.

Standards. Agency managers shall incorporate basic management controls in the strategies, plans, guidance and procedures that govern their programs and operations. Controls shall be consistent with the following standards, which are drawn in large part from the "Standards for Internal Control in the Federal Government," issued by the General Accounting Office (GAO).

General management control standards are:

Compliance With Law. All program operations, obligations and costs must comply with applicable law and regulation. Resources should be efficiently and effectively allocated for duly authorized purposes.

Reasonable Assurance and Safeguards. Management controls must provide reasonable assurance that assets are safeguarded against waste, loss, unauthorized use, and misappropriation. Management controls developed for agency programs should be logical, applicable, reasonably complete, and effective and efficient in accomplishing management objectives.

Integrity, Competence, and Attitude. Managers and employees must have personal integrity and are obligated to support the ethics programs in their agencies. The spirit of the Standards of Ethical Conduct requires that they develop and implement effective management controls and maintain a level of competence that allows them to accomplish their assigned duties. Effective communication within and between offices should be encouraged.

Specific management control standards are:

Delegation of Authority and Organization. Managers should ensure that appropriate authority, responsibility and accountability are defined and delegated to accomplish the mission of the organization, and that an appropriate organizational structure is established to effectively carry out program responsibilities. To the extent possible, controls and related decision-making authority should be in the hands of line managers and staff.

Separation of Duties and Supervision. Key duties and responsibilities in authorizing, processing, recording, and reviewing official agency transactions should be separated among individuals. Managers should exercise appropriate oversight to ensure individuals do not exceed or abuse their assigned authorities.

Access to and Accountability for Resources. Access to resources and records should be limited to authorized individuals, and accountability for the custody and use of resources should be assigned and maintained.

Recording and Documentation. Transactions should be promptly recorded, properly classified and accounted for in order to prepare timely accounts and reliable financial and other reports. The documentation for transactions, management controls, and other significant events must be clear and readily available for examination.

Resolution of Audit Findings and Other Deficiencies. Managers should promptly evaluate and determine proper actions in response to known deficiencies, reported audit and other findings, and related recommendations. Managers should complete, within established timeframes, all actions that correct or otherwise resolve the appropriate matters brought to management's attention.

Other policy documents may describe additional specific standards for particular functional or program activities. For example, OMB Circular No. A-127, "Financial Management Systems," describes government-wide requirements for financial systems. The Federal Acquisition Regulations define requirements for agency procurement activities.

III. ASSESSING AND IMPROVING MANAGEMENT CONTROLS

Agency managers should continuously monitor and improve the effectiveness of management controls associated with their programs. This continuous monitoring, and other periodic evaluations, should provide the basis for the agency head's annual assessment of and report on management controls, as required by the Integrity Act. Agency management should determine the appropriate level of documentation needed to support this assessment.

Sources of Information. The agency head's assessment of management controls can be performed using a variety of information sources. Management has primary responsibility for monitoring and assessing controls, and should use other sources as a supplement to -- not a replacement for -- its own judgment. Sources of information include:

Management knowledge gained from the daily operation of agency programs and systems.

Management reviews conducted (i) expressly for the purpose of assessing management controls, or (ii) for other purposes with an assessment of management controls as a by-product of the review.

IG and GAO reports, including audits, inspections, reviews, investigations, outcome of hotline complaints, or other products.

Program evaluations.

Audits of financial statements conducted pursuant to the Chief Financial Officers Act, as amended, including: information revealed in preparing the financial statements; the auditor's reports on the financial statements, internal controls, and compliance with laws and regulations; and any other materials prepared relating to the statements.

Reviews of financial systems which consider whether the requirements of OMB Circular No. A-127 are being met.

Reviews of systems and applications conducted pursuant to the Computer Security Act of 1987 (40 U.S.C. 759 note) and OMB Circular No. A-130, "Management of Federal Information Resources."

Annual performance plans and reports pursuant to the Government Performance and Results Act.

Reports and other information provided by the Congressional committees of jurisdiction.

Other reviews or reports relating to agency operations, e.g. for the Department of Health and Human Services, quality control reviews of the Medicaid and Aid to Families with Dependent Children programs.

Use of a source of information should take into consideration whether the process included an evaluation of management controls. Agency management should avoid duplicating reviews which assess management controls, and should coordinate their efforts with other evaluations to the extent practicable.

If a Federal manager determines that there is insufficient information available upon which to base an assessment of management controls, then appropriate reviews should be conducted which will provide such a basis.

Identification of Deficiencies. Agency managers and employees should identify deficiencies in management controls from the sources of information described above. A deficiency should be reported if it is or should be of interest to the next level of management. Agency employees and managers generally report deficiencies to the next supervisory level, which allows the chain of command structure to determine the relative importance of each deficiency.

A deficiency that the agency head determines to be significant enough to be reported outside the agency (i.e. included in the annual Integrity Act report to the President and the Congress) shall be considered a "material weakness."This Circular's use of the term "material weakness" should not be confused with use of the same term by government auditors to identify management control weaknesses which, in their opinion, pose a risk or a threat to the internal control systems of an audited entity, such as a program or operation. Auditors are required to identify and report those types of weaknesses at any level of operation or organization, even if the management of the audited entity would not report the weaknesses outside the agency. This designation requires a judgment by agency managers as to the relative risk and significance of deficiencies. Agencies may wish to use a different term to describe less significant deficiencies, which are reported only internally in an agency. In identifying and assessing the relative importance of deficiencies, particular attention should be paid to the views of the agency's IG.

Agencies should carefully consider whether systemic problems exist that adversely affect management controls across organizational or program lines. The Chief Financial Officer, the Senior Procurement Executive, the Senior IRM Official, and the managers of other functional offices should be involved in identifying and ensuring correction of systemic deficiencies relating to their respective functions.

Agency managers and staff should be encouraged to identify and report deficiencies, as this reflects positively on the agency's commitment to recognizing and addressing management problems. Failing to report a known deficiency would reflect adversely on the agency.

Role of A Senior Management Council. Many agencies have found that a senior management council is a useful forum for assessing and monitoring deficiencies in management controls. The membership of such councils generally includes both line and staff management; consideration should be given to involving the IG. Such councils generally recommend to the agency head which deficiencies are deemed to be material to the agency as a whole, and should therefore be included in the annual Integrity Act report to the President and the Congress. (Such a council need not be exclusively devoted to management control issues.) This process will help identify deficiencies that although minor individually, may constitute a material weakness in the aggregate. Such a council may also be useful in determining when sufficient action has been taken to declare that a deficiency has been corrected.

IV. CORRECTING MANAGEMENT CONTROL DEFICIENCIES

Agency managers are responsible for taking timely and effective action to correct deficiencies identified by the variety of sources discussed in Section III. Correcting deficiencies is an integral part of management accountability and must be considered a priority by the agency.

The extent to which corrective actions are tracked by the agency should be commensurate with the severity of the deficiency. Corrective action plans should be developed for all material weaknesses, and progress against plans should be periodically assessed and reported to agency management. Management should track progress to ensure timely and effective results. For deficiencies that are not included in the Integrity Act report, corrective action plans should be developed and tracked internally at the appropriate level.

A determination that a deficiency has been corrected should be made only when sufficient corrective actions have been taken and the desired results achieved. This determination should be in writing, and along with other appropriate documentation, should be available for review by appropriate officials. (See also role of senior management council in Section III.)

As managers consider IG and GAO audit reports in identifying and correcting management control deficiencies, they must be mindful of the statutory requirements for audit followup included in the IG Act, as amended. Under this law, management has a responsibility to complete action, in a timely manner, on audit recommendations on which agreement with the IG has been reached. 5 U.S.C. Appendix 3. (Management must make a decision regarding IG audit recommendations within a six month period and implementation of management's decision should be completed within one year to the extent practicable.) Agency managers and the IG share responsibility for ensuring that IG Act requirements are met.

V. REPORTING ON MANAGEMENT CONTROLS

Reporting Pursuant to Section 2. 31 U.S.C. 3512(d)(2) (commonly referred to as Section 2 of the Integrity Act) requires that annually by December 31, the head of each executive agency submit to the President and the Congress (i) a statement on whether there is reasonable assurance that the agency's controls are achieving their intended objectives; and (ii) a report on material weaknesses in the agency's controls. OMB may provide guidance on the composition of the annual report.

Statement of Assurance. The statement on reasonable assurance represents the agency head's informed judgment as to the overall adequacy and effectiveness of management controls within the agency. The statement must take one of the following forms: statement of assurance; qualified statement of assurance, considering the exceptions explicitly noted; or statement of no assurance.

In deciding on the type of assurance to provide, the agency head should consider information from the sources described in Section III of this Circular, with input from senior program and administrative officials and the IG. The agency head must describe the analytical basis for the type of assurance being provided, and the extent to which agency activities were assessed. The statement of assurance must be signed by the agency head.

Report on Material Weaknesses. The Integrity Act report must include agency plans to correct the material weaknesses and progress against those plans.

Reporting Pursuant to Section 4. 31 U.S.C. 3512(d)(2)(B) (commonly referred to as Section 4 of the Integrity Act) requires an annual statement on whether the agency's financial management systems conform with government-wide requirements. These financial systems requirements are presented in OMB Circular No. A-127, "Financial Management Systems," section 7. If the agency does not conform with financial systems requirements, the statement must discuss the agency's plans for bringing its systems into compliance.

If the agency head judges a deficiency in financial management systems and/or operations to be material when weighed against other agency deficiencies, the issue must be included in the annual Integrity Act report in the same manner as other material weaknesses.

Distribution of Integrity Act Report. The assurance statements and information related to both Sections 2 and 4 should be provided in a single Integrity Act report. Copies of the report are to be transmitted to the President; the President of the Senate; the Speaker of the House of Representatives; the Director of OMB; and the Chairpersons and Ranking Members of the Senate Committee on Governmental Affairs, the House Committee on Government Reform and Oversight, and the relevant authorizing and appropriations committees and subcommittees. In addition, 10 copies of the report are to be provided to OMB's Office of Federal Financial Management, Management Integrity Branch. Agencies are also encouraged to make their reports available electronically.

Streamlined Reporting. The Government Management Reform Act (GMRA) of 1994 (P.L. 103-356) permits OMB for fiscal years 1995 through 1997 to consolidate or adjust the frequency and due dates of certain statutory financial management reports after consultation with the Congress. GMRA prompted the CFO Council to recommend to OMB a new approach towards financial management reporting which could help integrate management initiatives. This proposal is being pilot-tested by several agencies for FY 1995. Further information on the implications of this initiative for other agencies will be issued by OMB after the pilot reports have been evaluated. In the meantime, the reporting requirements outlined in this Circular remain valid except for those agencies identified as pilots by OMB.

Under the CFO Council approach, agencies would consolidate Integrity Act information with other performance-related reporting into a broader "Accountability Report" to be issued annually by the agency head. This report would be issued as soon as possible after the end of the fiscal year, but no later than March 31 for agencies producing audited financial statements and December 31 for all other agencies. The proposed "Accountability Report" would integrate the following information: the Integrity Act report, management's Report on Final Action as required by the IG Act, the CFOs Act Annual Report (including audited financial statements), Civil Monetary Penalty and Prompt Payment Act reports, and available information on agency performance compared to its stated goals and objectives, in preparation for implementation of the GPRA.

Government Corporations. Section 306 of the Chief Financial Officers Act established a reporting requirement related to management controls for corporations covered by the Government Corporation and Control Act. 31 U.S.C. 9106. These corporations must submit an annual management report to the Congress not later than 180 days after the end of the corporation's fiscal year. This report must include, among other items, a statement on control systems by the head of the management of the corporation consistent with the requirements of the Integrity Act.

The corporation is required to provide the President, the Director of OMB, and the Comptroller General a copy of the management report when it is submitted to Congress.

OMB Circular No. A-130, Appendix III, Revised

EXECUTIVE OFFICE OF THE PRESIDENT

OFFICE OF MANAGEMENT AND BUDGET

WASHINGTON, D.C. 20503

February 8, 1996

CIRCULAR NO. A-130, Revised

(Transmittal Memorandum No. 3)

MEMORANDUM FOR HEADS OF EXECUTIVE DEPARTMENTS AND ESTABLISHMENTS

SUBJECT: Management of Federal Information Resources

Circular No. A-130 provides uniform government-wide information resources management policies as required by the Paperwork Reduction Act of 1980, as amended by the Paperwork Reduction Act of 1995, 44 U.S.C. Chapter 35. This Transmittal Memorandum contains updated guidance on the "Security of Federal Automated Information Systems," Appendix III and makes minor technical revisions to the Circular to reflect the Paperwork Reduction Act of 1995 (P.L. 104-13).

(Signed)

Alice M. Rivlin

Director

Attachment

February 8, 1996

Appendix III to OMB Circular No. A-130 - Security of Federal Automated Information Resources

A. Requirements.

1. Purpose

This Appendix establishes a minimum set of controls to be included in Federal automated information security programs; assigns Federal agency responsibilities for the security of automated information; and links agency automated information security programs and agency management control systems established in accordance with OMB Circular No. A-123. The Appendix revises procedures formerly contained in Appendix III to OMB Circular No. A-130 (50 FR 52730; December 24, 1985), and incorporates requirements of the Computer Security Act of 1987 (P.L. 100-235) and responsibilities assigned in applicable national security directives.

2. Definitions

The term:

a. "adequate security" means 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 agency operate effectively and provide appropriate confidentiality, integrity, and availability, through the use of cost-effective management, personnel, operational, and technical controls.

b. "application" means the use of information resources (information and information technology) to satisfy a specific set of user requirements.

c. "general support system" or "system" means an interconnected set of information resources under the same direct management control which shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people. A system can be, for example, a local area network (LAN) including smart terminals that supports a branch office, an agency-wide backbone, a communications network, a departmental data processing center including its operating system and utilities, a tactical radio network, or a shared information processing service organization (IPSO).

d. "major application" 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. Note: All Federal applications require some level of protection. Certain applications, because of the information in them, however, require special management oversight and should be treated as major. Adequate security for other applications should be provided by security of the systems in which they operate.

3. Automated Information Security Programs. Agencies shall implement and maintain a program to assure that adequate security is provided for all agency information collected, processed, transmitted, stored, or disseminated in general support systems and major applications.

Each agency's program shall implement policies, standards and procedures which are consistent with government-wide policies, standards, and procedures issued by the Office of Management and Budget, the Department of Commerce, the General Services Administration and the Office of Personnel Management (OPM). Different or more stringent requirements for securing national security information should be incorporated into agency programs as required by appropriate national security directives. At a minimum, agency programs shall include the following controls in their general support systems and major applications:

a. Controls for general support systems.

1) Assign Responsibility for Security. Assign responsibility for security in each system to an individual knowledgeable in the information technology used in the system and in providing security for such technology.

2) System Security Plan. Plan for adequate security of each general support system as part of the organization's information resources management (IRM) planning process. The security plan shall be consistent with guidance issued by the National Institute of Standards and Technology (NIST). Independent advice and comment on the security plan shall be solicited prior to the plan's implementation. A summary of the security plans shall be incorporated into the strategic IRM plan required by the Paperwork Reduction Act (44 U.S.C. Chapter 35) and Section 8(b) of this circular. Security plans shall include:

a) Rules of the System. Establish a set of rules of behavior concerning use of, security in, and the acceptable level of risk for, the system. The rules shall be based on the needs of the various users of the system. The security required by the rules shall be only as stringent as necessary to provide adequate security for information in the system. Such rules shall clearly delineate responsibilities and expected behavior of all individuals with access to the system. They shall also include appropriate limits on interconnections to other systems and shall define service provision and restoration priorities. Finally, they shall be clear about the consequences of behavior not consistent with the rules.

b) Training. Ensure that all individuals are appropriately trained in how to fulfill their security responsibilities before allowing them access to the system. Such training shall assure that employees are versed in the rules of the system, be consistent with guidance issued by NIST and OPM, and apprise them about available assistance and technical security products and techniques. Behavior consistent with the rules of the system and periodic refresher training shall be required for continued access to the system.

c) Personnel Controls. Screen individuals who are authorized to bypass significant technical and operational security controls of the system commensurate with the risk and magnitude of harm they could cause. Such screening shall occur prior to an individual being authorized to bypass controls and periodically thereafter.

d) Incident Response Capability. Ensure that there is a capability to provide help to users when a security incident occurs in the system and to share information concerning common vulnerabilities and threats. This capability shall share information with other organizations, consistent with NIST coordination, and should assist the agency in pursuing appropriate legal action, consistent with Department of Justice guidance.

e) Continuity of Support. Establish and periodically test the capability to continue providing service within a system based upon the needs and priorities of the participants of the system.

f) Technical Security. Ensure that cost-effective security products and techniques are appropriately used within the system.

g) System Interconnection. Obtain written management authorization, based upon the acceptance of risk to the system, prior to connecting with other systems. Where connection is authorized, controls shall be established which are consistent with the rules of the system and in accordance with guidance from NIST.

3) Review of Security Controls. Review the security controls in each system when significant modifications are made to the system, but at least every three years. The scope and frequency of the review should be commensurate with the acceptable level of risk for the system. Depending on the potential risk and magnitude of harm that could occur, consider identifying a deficiency pursuant to OMB Circular No. A-123, "Management Accountability and Control" and the Federal Managers' Financial Integrity Act (FMFIA), if there is no assignment of security responsibility, no security plan, or no authorization to process for a system.

4) Authorize Processing. Ensure that a management official authorizes in writing the use of each general support system based on implementation of its security plan before beginning or significantly changing processing in the system. Use of the system shall be re-authorized at least every three years.

b. Controls for Major Applications.

1) Assign Responsibility for Security. Assign responsibility for security of each major application to a management official knowledgeable in the nature of the information and process supported by the application and in the management, personnel, operational, and technical controls used to protect it. This official shall assure that effective security products and techniques are appropriately used in the application and shall be contacted when a security incident occurs concerning the application.

2) Application Security Plan. Plan for the adequate security each major application, taking into account the security of all systems in which the application will operate. The plan shall be consistent with guidance issued by NIST. Advice and comment on the plan shall be solicited from the official responsible for security in the primary system in which the application will operate prior to the plan's implementation. A summary of the security plans shall be incorporated into the strategic IRM plan required by the Paperwork Reduction Act. Application security plans shall include:

a) Application Rules. Establish a set of rules concerning use of and behavior within the application. The rules shall be as stringent as necessary to provide adequate security for the application and the information in it. Such rules shall clearly delineate responsibilities and expected behavior of all individuals with access to the application. In addition, the rules shall be clear about the consequences of behavior not consistent with the rules.

b) Specialized Training. Before allowing individuals access to the application, ensure that all individuals receive specialized training focused on their responsibilities and the application rules. This may be in addition to the training required for access to a system. Such training may vary from a notification at the time of access (e.g., for members of the public using an information retrieval application) to formal training (e.g., for an employee that works with a high-risk application).

c) Personnel Security. Incorporate controls such as separation of duties, least privilege and individual accountability into the application and application rules as appropriate. In cases where such controls cannot adequately protect the application or information in it, screen individuals commensurate with the risk and magnitude of the harm they could cause. Such screening shall be done prior to the individuals' being authorized to access the application and periodically thereafter.

d) Contingency Planning. Establish and periodically test the capability to perform the agency function supported by the application in the event of failure of its automated support.

e) Technical Controls. Ensure that appropriate security controls are specified, designed into, tested, and accepted in the application in accordance with appropriate guidance issued by NIST.

f) Information Sharing. Ensure that information shared from the application is protected appropriately, comparable to the protection provided when information is within the application.

g) Public Access Controls. Where an agency's application promotes or permits public access, additional security controls shall be added to protect the integrity of the application and the confidence the public has in the application. Such controls shall include segregating information made directly accessible to the public from official agency records.

3) Review of Application Controls. Perform an independent review or audit of the security controls in each application at least every three years. Consider identifying a deficiency pursuant to OMB Circular No. A-123, "Management Accountability and Control" and the Federal Managers' Financial Integrity Act if there is no assignment of responsibility for security, no security plan, or no authorization to process for the application.

4) Authorize Processing. Ensure that a management official authorizes in writing use of the application by confirming that its security plan as implemented adequately secures the application. Results of the most recent review or audit of controls shall be a factor in management authorizations. The application must be authorized prior to operating and re-authorized at least every three years thereafter. Management authorization implies accepting the risk of each system used by the application.

4. Assignment of Responsibilities

a. Department of Commerce. The Secretary of Commerce shall:

1) Develop and issue appropriate standards and guidance for the security of sensitive information in Federal computer systems.

2) Review and update guidelines for training in computer security awareness and accepted computer security practice, with assistance from OPM.

3) Provide agencies guidance for security planning to assist in their development of application and system security plans.

4) Provide guidance and assistance, as appropriate, to agencies concerning cost-effective controls when interconnecting with other systems.

5) Coordinate agency incident response activities to promote sharing of incident response information and related vulnerabilities.

6) Evaluate new information technologies to assess their security vulnerabilities, with technical assistance from the Department of Defense, and apprise Federal agencies of such vulnerabilities as soon as they are known.

b. Department of Defense. The Secretary of Defense shall:

1) Provide appropriate technical advice and assistance (including work products) to the Department of Commerce.

2) Assist the Department of Commerce in evaluating the vulnerabilities of emerging information technologies.

c. Department of Justice. The Attorney General shall:

1) Provide appropriate guidance to agencies on legal remedies regarding security incidents and ways to report and work with law enforcement concerning such incidents.

2) Pursue appropriate legal actions when security incidents occur.

d. General Services Administration. The Administrator of General Services shall:

1) Provide guidance to agencies on addressing security considerations when acquiring automated data processing equipment (as defined in section 111(a)(2) of the Federal Property and Administrative Services Act of 1949, as amended).

2) Facilitate the development of contract vehicles for agencies to use in the acquisition of cost-effective security products and services (e.g., back-up services).

3) Provide appropriate security services to meet the needs of Federal agencies to the extent that such services are cost-effective.

e. Office of Personnel Management. The Director of the Office of Personnel Management shall:

1) Assure that its regulations concerning computer security training for Federal civilian employees are effective.

2) Assist the Department of Commerce in updating and maintaining guidelines for training in computer security awareness and accepted computer security practice.

f. Security Policy Board. The Security Policy Board shall coordinate the activities of the Federal government regarding the security of information technology that processes classified information in accordance with applicable national security directives;

5. Correction of Deficiencies and Reports

a. Correction of Deficiencies. Agencies shall correct deficiencies which are identified through the reviews of security for systems and major applications described above.

b. Reports on Deficiencies. In accordance with OMB Circular No. A-123, "Management Accountability and Control", if a deficiency in controls is judged by the agency head to be material when weighed against other agency deficiencies, it shall be included in the annual FMFIA report. Less significant deficiencies shall be reported and progress on corrective actions tracked at the appropriate agency level.

c. Summaries of Security Plans. Agencies shall include a summary of their system security plans and major application plans in the strategic plan required by the Paperwork Reduction Act (44 U.S.C. 3506).

B. Descriptive Information.

The following descriptive language is explanatory. It is included to assist in understanding the requirements of the Appendix.

The Appendix re-orients the Federal computer security program to better respond to a rapidly changing technological environment. It establishes government-wide responsibilities for Federal computer security and requires Federal agencies to adopt a minimum set of management controls. These management controls are directed at individual information technology users in order to reflect the distributed nature of today's technology.

For security to be most effective, the controls must be part of day-to-day operations. This is best accomplished by planning for security not as a separate activity, but as an integral part of overall planning.

"Adequate security" is defined as "security commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information." This definition explicitly emphasizes the risk-based policy for cost-effective security established by the Computer Security Act.

The Appendix no longer requires the preparation of formal risk analyses. In the past, substantial resources have been expended doing complex analyses of specific risks to systems, with limited tangible benefit in terms of improved security for the systems. Rather than continue to try to precisely measure risk, security efforts are better served by generally assessing risks and taking actions to manage them. While formal risk analyses need not be performed, the need to determine adequate security will require that a risk-based approach be used. This risk assessment approach should include a consideration of the major factors in risk management: the value of the system or application, threats, vulnerabilities, and the effectiveness of current or proposed safeguards. Additional guidance on effective risk assessment is available in "An Introduction to Computer Security: The NIST Handbook" (March 16, 1995).

Discussion of the Appendix's Major Provisions. The following discussion is provided to aid reviewers in understanding the changes in emphasis in the Appendix.

Automated Information Security Programs. Agencies are required to establish controls to assure adequate security for all information processed, transmitted, or stored in Federal automated information systems. This Appendix emphasizes management controls affecting individual users of information technology. Technical and operational controls support management controls. To be effective, all must interrelate. For example, authentication of individual users is an important management control, for which password protection is a technical control. However, password protection will only be effective if both a strong technology is employed, and it is managed to assure that it is used correctly.

Four controls are set forth: assigning responsibility for security, security planning, periodic review of security controls, and management authorization. The Appendix requires that these management controls be applied in two areas of management responsibility: one for general support systems and one for major applications.

The terms "general support system" and "major application" were used in OMB Bulletins Nos. 88-16 and 90-08. A general support system is "an interconnected set of information resources under the same direct management control which shares common functionality." Such a system can be, for example, a local area network (LAN) including smart terminals that supports a branch office, an agency-wide backbone, a communications network, a departmental data processing center including its operating system and utilities, a tactical radio network, or a shared information processing service organization. Normally, the purpose of a general support system is to provide processing or communications support.

A major application is a use of information and information technology to satisfy a specific set of user requirements that requires special management attention to security due to the risk and magnitude of harm resulting from the loss, misuse or unauthorized access to or modification of the information in the application. All applications require some level of security, and adequate security for most of them should be provided by security of the general support systems in which they operate. However, certain applications, because of the nature of the information in them, require special management oversight and should be treated as major. Agencies are expected to exercise management judgement in determining which of their applications are major.

The focus of OMB Bulletins Nos. 88-16 and 90-08 was on identifying and securing both general support systems and applications which contained sensitive information. The Appendix requires the establishment of security controls in all general support systems, under the presumption that all contain some sensitive information, and focuses extra security controls on a limited number of particularly high-risk or major applications.

a. General Support Systems. The following controls are required in all general support systems:

1) Assign Responsibility for Security. For each system, an individual should be a focal point for assuring there is adequate security within the system, including ways to prevent, detect, and recover from security problems. That responsibility should be assigned in writing to an individual trained in the technology used in the system and in providing security for such technology, including the management of security controls such as user identification and authentication.

2) Security Plan. The Computer Security Act requires that security plans be developed for all Federal computer systems that contain sensitive information. Given the expansion of distributed processing since passage of the Act, the presumption in the Appendix is that all February 8, 1996 general support systems contain some sensitive information which requires protection to assure its integrity, availability, or confidentiality, and therefore all systems require security plans.

Previous guidance on security planning was contained in OMB Bulletin No. 90-08. This Appendix supersedes OMB Bulletin 90-08 and expands the coverage of security plans from Bulletin 90-08 to include rules of individual behavior as well as technical security. Consistent with OMB Bulletin 90-08, the Appendix directs NIST to update and expand security planning guidance and issue it as a Federal Information Processing Standard (FIPS). In the interim, agencies should continue to use the Appendix of OMB Bulletin No. 90-08 as guidance for the technical portion of their security plans.

The Appendix continues the requirement that independent advice and comment on the security plan for each system be sought. The intent of this requirement is to improve the plans, foster communication between managers of different systems, and promote the sharing of security expertise.

This Appendix also continues the requirement from the Computer Security Act that summaries of security plans be included in agency strategic information resources management plans. OMB will provide additional guidance about the contents of those strategic plans, pursuant to the Paperwork Reduction Act of 1995.

The following specific security controls should be included in the security plan for a general support system:

a) Rules. An important new requirement for security plans is the establishment of a set of rules of behavior for individual users of each general support system. These rules should clearly delineate responsibilities of and expectations for all individuals with access to the system. They should be consistent with system-specific policy as described in "An Introduction to Computer Security: The NIST Handbook" (March 16, 1995). In addition, they should state the consequences of non-compliance. The rules should be in writing and will form the basis for security awareness and training.

The development of rules for a system must take into consideration the needs of all parties who use the system. Rules should be as stringent as necessary to provide adequate security. Therefore, the acceptable level of risk for the system must be established and should form the basis for determining the rules.

Rules should cover such matters as work at home, dial-in access, connection to the Internet, use of copyrighted works, unofficial use of government equipment, the assignment and limitation of system privileges, and individual accountability. Often rules should reflect technical security controls in the system. For example, rules regarding password use should be consistent with technical password features in the system. Rules may be enforced through administrative sanctions specifically related to the system (e.g. loss of system privileges) or through more general sanctions as are imposed for violating other rules of conduct. In addition, the rules should specifically address restoration of service as a concern of all users of the system.

b) Training. The Computer Security Act requires Federal agencies to provide for the mandatory periodic training in computer security awareness and accepted computer security practice of all employees who are involved with the management, use or operation of a Federal computer system within or under the supervision of the Federal agency. This includes contractors as well as employees of the agency. Access provided to members of the public should be constrained by controls in the applications through which access is allowed, and training should be within the context of those controls. The Appendix enforces such mandatory training by requiring its completion prior to granting access to the system. Each new user of a general support system in some sense introduces a risk to all other users. Therefore, each user should be versed in acceptable behavior -- the rules of the system -- before being allowed to use the system. Training should also inform the individual how to get help in the event of difficulty with using or security of the system.

Training should be tailored to what a user needs to know to use the system securely, given the nature of that use. Training may be presented in stages, for example as more access is granted. In some cases, the training should be in the form of classroom instruction. In other cases, interactive computer sessions or well-written and understandable brochures may be sufficient, depending on the risk and magnitude of harm.

Over time, attention to security tends to dissipate. In addition, changes to a system may necessitate a change in the rules or user procedures. Therefore, individuals should periodically have refresher training to assure that they continue to understand and abide by the applicable rules.

To assist agencies, the Appendix requires NIST, with assistance from the Office of Personnel Management (OPM), to update its existing guidance. It also proposes that OPM assure that its rules for computer security training for Federal civilian employees are effective.

c) Personnel Controls. It has long been recognized that the greatest harm has come from authorized individuals engaged in improper activities, whether intentional or accidental. In every general support system, a number of technical, operational, and management controls are used to prevent and detect harm. Such controls include individual accountability, "least privilege," and separation of duties.

Individual accountability consists of holding someone responsible for his or her actions. In a general support system, accountability is normally accomplished by identifying and authenticating users of the system and subsequently tracing actions on the system to the user who initiated them. This may be done, for example, by looking for patterns of behavior by users.

Least privilege is the practice of restricting a user's access (to data files, to processing capability, or to peripherals) or type of access (read, write, execute, delete) to the minimum necessary to perform his or her job.

Separation of duties is the practice of dividing the steps in a critical function among different individuals. For example, one system programmer can create a critical piece of operating system code, while another authorizes its implementation. Such a control keeps a single individual from subverting a critical process.

Nevertheless, in some instances, individuals may be given the ability to bypass some significant technical and operational controls in order to perform system administration and maintenance functions (e.g., LAN administrators or systems programmers).

Screening such individuals in positions of trust will supplement technical, operational, and management controls, particularly where the risk and magnitude of harm is high.

d) Incident Response Capability. Security incidents, whether caused by viruses, hackers, or software bugs, are becoming more common. When faced with a security incident, an agency should be able to respond in a manner that both protects its own information and helps to protect the information of others who might be affected by the incident. To address this concern, agencies should establish formal incident response mechanisms. Awareness and training for individuals with access to the system should include how to use the system's incident response capability.

To be fully effective, incident handling must also include sharing information concerning common vulnerabilities and threats with those in other systems and other agencies. The Appendix directs agencies to effectuate such sharing, and tasks NIST to coordinate those agency activities government-wide.

The Appendix also directs the Department of Justice to provide appropriate guidance on pursuing legal remedies in the case of serious incidents.

e) Continuity of Support. Inevitably, there will be service interruptions. Agency plans should assure that there is an ability to recover and provide service sufficient to meet the minimal needs of users of the system. Manual procedures are generally NOT a viable back-up option. When automated support is not available, many functions of the organization will effectively cease. Therefore, it is important to take cost-effective steps to manage any disruption of service.

Decisions on the level of service needed at any particular time and on priorities in service restoration should be made in consultation with the users of the system and incorporated in the system rules. Experience has shown that recovery plans that are periodically tested are substantially more viable than those that are not. Moreover, untested plans may actually create a false sense of security.

f) Technical Security. Agencies should assure that each system appropriately uses effective security products and techniques, consistent with standards and guidance from NIST. Often such techniques will correspond with system rules of behavior, such as in the proper use of password protection.

The Appendix directs NIST to continue to issue computer security guidance to assist agencies in planning for and using technical security products and techniques. Until such guidance is issued, however, the planning guidance included in OMB Bulletin 90-08 can assist in determining techniques for effective security in a system and in addressing technical controls in the security plan.

g) System Interconnection. In order for a community to effectively manage risk, it must control access to and from other systems. The degree of such control should be established in the rules of the system and all participants should be made aware of any limitations on outside access. Technical controls to accomplish this should be put in place in accordance with guidance issued by NIST.

There are varying degrees of how connected a system is. For example, some systems will choose to isolate themselves, others will restrict access such as allowing only e-mail connections or remote access only with sophisticated authentication, and others will be fully open. The management decision to interconnect should be based on the availability and use of technical and non- technical safeguards and consistent with the acceptable level of risk defined in the system rules.

3) Review of Security Controls. The security of a system will degrade over time, as the technology evolves and as people and procedures change. Reviews should assure that management, operational, personnel, and technical controls are functioning effectively. Security controls may be reviewed by an independent audit or a self review. The type and rigor of review or audit should be commensurate with the acceptable level of risk that is established in the rules for the system and the likelihood of learning useful information to improve security.

Technical tools such as virus scanners, vulnerability assessment products (which look for known security problems, configuration errors, and the installation of the latest patches), and penetration testing can assist in the on-going review of different facets of systems. However, these tools are no substitute for a formal management review at least every three years. Indeed, for some high-risk systems with rapidly changing technology, three years will be too long.

Depending upon the risk and magnitude of harm that could result, weaknesses identified during the review of security controls should be reported as deficiencies in accordance with OMB Circular No. A-123, "Management Accountability and Control" and the Federal Managers' Financial Integrity Act. In particular, if a basic management control such as assignment of responsibility, a workable security plan, or management authorization are missing, then consideration should be given to identifying a deficiency.

4) Authorize Processing. The authorization of a system to process information, granted by a management official, provides an important quality control (some agencies refer to this authorization as accreditation). By authorizing processing in a system, a manager accepts the risk associated with it. Authorization is not a decision that should be made by the security staff.

Both the security official and the authorizing management official have security responsibilities. In general, the security official is closer to the day-to-day operation of the system and will direct or perform security tasks. The authorizing official will normally have general responsibility for the organization supported by the system.

Management authorization should be based on an assessment of management, operational, and technical controls. Since the security plan establishes the security controls, it should form the basis for the authorization, supplemented by more specific studies as needed. In addition, the periodic review of controls should also contribute to future authorizations. Some agencies perform "certification reviews" of their systems periodically. These formal technical evaluations lead to a management accreditation, or "authorization to process." Such certifications (such as those using the methodology in FIPS Pub 102 "Guideline for Computer Security Certification and Accreditation") can provide useful information to assist management in authorizing a system, particularly when combined with a review of the broad behavioral controls envisioned in the security plan required by the Appendix.

Re-authorization should occur prior to a significant change in processing, but at least every three years. It should be done more often where there is a high risk and potential magnitude of harm.

b. Controls in Major Applications. Certain applications require special management attention due to the risk and magnitude of harm that could occur. For such applications, the controls of the support system(s) in which they operate are likely to be insufficient. Therefore, additional controls specific to the application are required. Since the function of applications is the direct manipulation and use of information, controls for securing applications should emphasize protection of information and the way it is manipulated.

1) Assign Responsibility for Security. By definition, major applications are high risk and require special management attention. Major applications usually support a single agency function and often are supported by more than one general support system. It is important, therefore, that an individual be assigned responsibility in writing to assure that the particular application has adequate security. To be effective, this individual should be knowledgeable in the information and process supported by the application and in the management, personnel, operational, and technical controls used to protect the application.

2) Application Security Plans. Security for each major application should be addressed by a security plan specific to the application. The plan should include controls specific to protecting information and should be developed from the application manager's perspective. To assist in assuring its viability, the plan should be provided to the manager of the primary support system which the application uses for advice and comment. This recognizes the critical dependence of the security of major applications on the underlying support systems they use. Summaries of application security plans should be included in strategic information resource management plans in accordance with this Circular.

a) Application Rules. Rules of behavior should be established which delineate the responsibilities and expected behavior of all individuals with access to the application. The rules should state the consequences of inconsistent behavior. Often the rules will be associated with technical controls implemented in the application. Such rules should include, for example, limitations on changing data, searching databases, or divulging information.

b) Specialized Training. Training is required for all individuals given access to the application, including members of the public. It should vary depending on the type of access allowed and the risk that access represents to the security of the application and information in it. This training will be in addition to that required for access to a support system.

c) Personnel Security. For most major applications, management controls such as individual accountability requirements, separation of duties enforced by access controls, or limitations on the processing privileges of individuals, are generally more cost-effective personnel security controls than background screening. Such controls should be implemented as both technical controls and as application rules. For example, technical controls to ensure individual accountability, such as looking for patterns of user behavior, are most effective if users are aware that there is such a technical control. If adequate audit or access controls (through both technical and non-technical methods) cannot be established, then it may be cost-effective to screen personnel, commensurate with the risk and magnitude of harm they could cause. The change in emphasis on screening in the Appendix should not affect background screening deemed necessary because of other duties that an individual may perform.

d) Contingency Planning. Normally the Federal mission supported by a major application is critically dependent on the application. Manual processing is generally NOT a viable back-up option. Managers should plan for how they will perform their mission and/or recover from the loss of existing application support, whether the loss is due to the inability of the application to function or a general support system failure. Experience has demonstrated that testing a contingency plan significantly improves its viability. Indeed, untested plans or plans not tested for a long period of time may create a false sense of ability to recover in a timely manner.

e) Technical Controls. Technical security controls, for example tests to filter invalid entries, should be built into each application. Often these controls will correspond with the rules of behavior for the application. Under the previous Appendix, application security was focused on the process by which sensitive, custom applications were developed. While that process is not addressed in detail in this Appendix, it remains an effective method for assuring that security controls are built into applications. Additionally, the technical security controls defined in OMB Bulletin No. 90-08 will continue, until that guidance is replaced by NIST's security planning guidance.

f) Information Sharing. Assure that information which is shared with Federal organizations, State and local governments, and the private sector is appropriately protected comparable to the protection provided when the information is within the application. Controls on the information may stay the same or vary when the information is shared with another entity. For example, the primary user of the information may require a high level of availability while the secondary user does not, and can therefore relax some of the controls designed to maintain the availability of the information. At the same time, however, the information shared may require a level of confidentiality that should be extended to the secondary user. This normally requires notification and agreement to protect the information prior to its being shared.

g) Public Access Controls. Permitting public access to a Federal application is an important method of improving information exchange with the public. At the same time, it introduces risks to the Federal application. To mitigate these risks, additional controls should be in place as appropriate. These controls are in addition to controls such as "firewalls" that are put in place for security of the general support system.

In general, it is more difficult to apply conventional controls to public access systems, because many of the users of the system may not be subject to individual accountability policies. In addition, public access systems may be a target for mischief because of their higher visibility and published access methods.

Official records need to be protected against loss or alteration. Official records in electronic form are particularly susceptible since they can be relatively easy to change or destroy. Therefore, official records should be segregated from information made directly accessible to the public. There are different ways to segregate records. Some agencies and organizations are creating dedicated information dissemination systems (such as bulletin boards or World Wide Web servers) to support this function. These systems can be on the outside of secure gateways which protect internal agency records from outside access.

In order to secure applications that allow direct public access, conventional techniques such as least privilege (limiting the processing capability as well as access to data) and integrity assurances (such as checking for viruses, clearly labeling the age of data, or periodically spot checking data) should also be used. Additional guidance on securing public access systems is available from NIST Computer Systems Laboratory Bulletin "Security Issues in Public Access Systems" (May, 1993).

3) Review of Application Controls. At least every three years, an independent review or audit of the security controls for each major application should be performed. Because of the higher risk involved in major applications, the review or audit should be independent of the manager responsible for the application. Such reviews should verify that responsibility for the security of the application has been assigned, that a viable security plan for the application is in place, and that a manager has authorized the processing of the application. A deficiency in any of these controls should be considered a deficiency pursuant to the Federal Manager's Financial Integrity Act and OMB Circular No. A-123, "Management Accountability and Control."

The review envisioned here is different from the system test and certification process required in the current Appendix. That process, however, remains useful for assuring that technical security features are built into custom-developed software applications. While the controls in that process are not specifically called for in this Appendix, they remain in Bulletin No. 90-08, and are recommended in appropriate circumstances as technical controls.

4) Authorize Processing. A major application should be authorized by the management official responsible for the function supported by the application at least every three years, but more often where the risk and magnitude of harm is high. The intent of this requirement is to assure that the senior official whose mission will be adversely affected by security weaknesses in the application periodically assesses and accepts the risk of operating the application. The authorization should be based on the application security plan and any review(s) performed on the application. It should also take into account the risks from the general support systems used by the application.

4. Assignment of Responsibilities. The Appendix assigns government-wide responsibilities to agencies that are consistent with their missions and the Computer Security Act.

a. Department of Commerce. The Department of Commerce, through NIST, is assigned the following responsibilities consistent with the Computer Security Act.

1) Develop and issue security standards and guidance.

2) Review and update, with assistance from OPM, the guidelines for security training issued in 1988 pursuant to the Computer Security Act to assure they are effective.

3) Replace and update the technical planning guidance in the appendix to OMB Bulletin 90-08 This should include guidance on effective risk-based security absent a formal risk analysis.

4) Provide agencies with guidance and assistance concerning effective controls for systems when interconnecting with other systems, including the Internet. Such guidance on, for example, so-called "firewalls" is becoming widely available and is critical to agencies as they consider how to interconnect their communications capabilities.

5) Coordinate agency incident response activities. Coordination of agency incident response activities should address both threats and vulnerabilities as well as improve the ability of the Federal government for rapid and effective cooperation in response to serious security breaches.

6) Assess security vulnerabilities in new information technologies and apprise Federal agencies of such vulnerabilities. The intent of this new requirement is to help agencies understand the security implications of technology before they purchase and field it. In the past, there have been too many instances where agencies have acquired and implemented technology, then found out about vulnerabilities in the technology and had to retrofit security measures. This activity is intended to help avoid such difficulties in the future.

b. Department of Defense. The Department, through the National Security Agency, should provide technical advice and assistance to NIST, including work products such as technical security guidelines, which NIST can draw upon for developing standards and guidelines for protecting sensitive information in Federal computers.

Also, the Department, through the National Security Agency, should assist NIST in evaluating vulnerabilities in emerging technologies. Such vulnerabilities may present a risk to national security information as well as to unclassified information.

c. Department of Justice. The Department of Justice should provide appropriate guidance to Federal agencies on legal remedies available to them when serious security incidents occur. Such guidance should include ways to report incidents and cooperate with law enforcement.

In addition, the Department should pursue appropriate legal actions on behalf of the Federal government when serious security incidents occur.

d. General Services Administration. The General Services Administration should provide agencies guidance for addressing security considerations when acquiring information technology products or services. This continues the current requirement.

In addition, where cost-effective to do so, GSA should establish government-wide contract vehicles for agencies to use to acquire certain security services. Such vehicles already exist for providing system back-up support and conducting security analyses.

GSA should also provide appropriate security services to assist Federal agencies to the extent that provision of such services is cost- effective. This includes providing, in conjunction with the Department of Defense and the Department of Commerce, appropriate services which support Federal use of the National Information Infrastructure (e.g., use of digital signature technology).

e. Office of Personnel Management. In accordance with the Computer Security Act, OPM should review its regulations concerning computer security training and assure that they are effective.

In addition, OPM should assist the Department of Commerce in the review and update of its computer security awareness and training guidelines. OPM worked closely with NIST in developing the current guidelines and should work with NIST in revising those guidelines.

f. Security Policy Board. The Security Policy Board is assigned responsibility for national security policy coordination in accordance with the appropriate Presidential directive. This includes policy for the security of information technology used to process classified information.

Circular A-130 and this Appendix do not apply to information technology that supports certain critical national security missions, as defined in 44 U.S.C. 3502(9) and 10 U.S.C. 2315. Policy and procedural requirements for the security of national security systems (telecommunications and information systems that contain classified information or that support those critical national security missions (44 U.S.C. 3502(9) and 10 U.S.C. 2315)) is assigned to the Department of Defense pursuant to Presidential directive. The Circular clarifies that information classified for national security purposes should also be handled in accordance with appropriate national security directives. Where classified information is required to be protected by more stringent security requirements, those requirements should be followed rather than the requirements of this Appendix.

5. Reports. The Appendix requires agencies to provide two reports to OMB:

The first is a requirement that agencies report security deficiencies and material weaknesses within their FMFIA reporting mechanisms as defined by OMB Circular No. A-123, "Management Accountability and Control," and take corrective actions in accordance with that directive.

The second, defined by the Computer Security Act, requires that a summary of agency security plans be included in the information resources management plan required by the Paperwork Reduction Act.

(This Page Intentionally Left Blank)

INDEX


31 U.S.C. 3512............................G-7, G-9, G-14, G-15
31 U.S.C. 9106............................G-16
88-16.................................... G-22, G-23
90-08.....................................Bib-6, G-22, G-23, G-26, G-28-G-30
Accreditation.............................1-6, 2-4, 2-6-2-9, 3-1, 3-2, 3-6-3-10,
                                          3-12, 4-1, 4-2, 4-6, 4-9-4-11, Glos-1,
                                          Glos-2,	Glos-5, Glos-9, Glos-18, Glos-19,
                                          Glos-21, Bib-2, Bib-7, D-3, G-27
Acquisition...............................2-4, 2-8, 2-10, 3-1, 3-2, 3-12, Bib-9,
                                          D-3, G-11, G-12, G-21
Adequate Security.........................1-1-1-3, Glos-2, Glos-15, B-3, G-17-G-19,
                                          G-22-G-24, G-27
AIS Owner.................................2-7, 3-1, Glos-2
Application...............................1-2, 1-3, 2-5, 2-6, 2-8, 3-4, 3-6, 3-7, 
                                          3-11, 3-12, 4-8, 4-12, Glos-2, Glos-3,
                                          Glos-11, Glos-15, Glos-18, Glos-19, 
                                          D-2-E-4, G-17, G-19, G-20, G-22, G-23,
                                          G-27-G-29
Application Owner.........................Glos-2, Glos-3, Glos-19
Approval..................................3-4, 3-7-3-9, 3-12, 4-3, 4-12, 4-13, 
                                          Glos-1, Glos-4
Audit.....................................2-8, 4-4, 4-7, Glos-3, C-1, E-4, F-2, G-3,
                                          G-10, G-12, G-14, G-20, G-26, G-28, G-29
Authority.................................2-1-2-3, 2-5, 2-10-2-12, 3-1, 3-11, 4-10,
                                          4-12, Glos-1-Glos-3, Glos-8, Glos-9, Glos-18,
                                          Glos-19, A-1, A-2, E-1-G-3, G-7, G-9, G-11
Availability..............................1-2, 3-4, Glos-2, Glos-4, Glos-6-Glos-8, B-2,
                                          C-1, D-2, G-17, G-23, G-26, G-28
Awareness.................................2-2, 2-3, 3-1, 3-10, 3-11, Bib-6, D-3, E-1-E-3,
                                          G-20, G-21, G-24, G-25, G-31
A-123.....................................Bib-2, Bib-7, G-1, G-7, G-17, G-19-G-21, G-26, G-29, G-31
A-127.....................................Bib-6, G-12, G-15
A-130.....................................1-1, 3-10, Glos-2, Glos-12, Glos-15, Glos-20,
                                          G-13, G-16, G-17, G-31
Back-up...................................G-21, G-25, G-28, G-30
Bacteria..................................Glos-4, Glos-15, Glos-25
Business Impact Analysis..................3-4
C2........................................2-3, 2-6, 2-9, 2-10, 4-3, 4-4, 4-6, 4-7, Glos-5,
                                          Glos-7, Glos-8, Glos-10, Glos-16, Glos-17,
                                          Glos-22-Glos-24, C-1, C-2, F-1, F-2
Certification.............................1-4, 2-7, 2-8, 3-1, 3-2, 3-6-3-8, 3-12, 4-6, 
                                          4-10, 4-11, Glos-1, Glos-5, Glos-20, Bib-2,
                                          Bib-7, D-3, G-27, G-29
CFO.......................................G-3, G-11, G-15
Chief Financial Officers (CFOs) Act.......G-2
Classification............................1-3, 4-10, 4-11, Glos-5-Glos-7, Glos-15, Glos-24,
                                          F-1
Classified................................1-3, 1-6, 3-8, 4-3, 4-11, 5-1, Glos-6, Glos-7, 
                                          Glos-10, Glos-15, Glos-22, Bib-1, Bib-3,	Bib-9,
                                          C-1, G-12, G-21, G-31
Clear.....................................4-4, G-10, G-12, G-18, G-19
Clearing..................................4-10, Glos-6, C-1, C-2
Commercial................................1-2, 3-7, 4-6, 4-13, Glos-2, Glos-3, Glos-6,
                                          Glos-7, Glos-23, Bib-7, A-1, E-2
Commissioner..............................III, 2-1, 2-3, 2-5, 2-6, Bib-8
Computer Security Act.....................3-10, Glos-5, Glos-6, Glos-19, Glos-22, Bib-2,
                                          Bib-8, E-1, G-13, G-17, G-22-G-24, G-29-G-31
Computer Security Incident Response.......Bib-9
COMSEC....................................1-5, 4-14, Glos-6, Bib-3, A-1, E-2
Confidentiality...........................1-2, Glos-2, Glos-6, Glos-7, Glos-16, C-1-D-3,
                                          G-17, G-23, G-28
Configuration Management..................2-8, 3-9, 3-11, 4-6, 4-9, Glos-7, D-3
Contingency...............................1-4, 2-5, 2-7, 3-1, Glos-7, Glos-8, Glos-10,
                                          Bib-6, D-3, G-19, G-28
Contingency Plan..........................4-11, Glos-7, Glos-10, G-28
Continuity of Operations..................3-4, 4-2, Glos-7, E-4
Continuity of Support.....................G-18, G-25
Contracting Officer.......................3-12
Copyright.................................4-9, Glos-13
COTR......................................3-12
COTS......................................3-7, 4-6, 4-13, Glos-6, Glos-7, A-1
CSIRC.....................................2-7, Bib-9
Customs Process...........................2-6, 3-1
Data Base.................................1-5, Glos-5
Data Encryption Standard..................Glos-9, A-1, C-3
Dedicated Security Mode...................3-7, 3-8, 4-12, Glos-9, Glos-23
Deficiencies..............................3-7, 3-9, G-3-G-6, G-10, G-12-G-15, G-21,
                                          G-26, G-31
Department of Justice.....................Bib-6, G-18, G-21, G-25, G-30
Diagnostic................................4-10
Dial-up...................................3-5, 4-10, C-1, C-3
Director..................................1-1, 2-3, 3-10, 4-13, E-1, G-2, G-6, G-7,
                                          G-15, G-16, G-21
Disaster..................................1-4, 2-5, 3-1-3-4, 3-11, 4-2, Glos-4, 
                                          Glos-7, Glos-8, Glos-10, Glos-19, Glos-23
Discretionary Access Control..............4-4, Glos-8, Glos-10, C-2
Distribution..............................III, 2-8, Glos-14, Glos-16, Glos-21, Bib-5,
                                          Bib-8, B-3, G-5, G-15
Education.................................2-2, 2-3, 3-1, 3-10
Emergency.................................2-7, 2-9, 3-2-3-4, Glos-7, Glos-10, Glos-11,
                                          Glos-19, Glos-20, Glos-25, D-3
Encryption................................2-10-2-12, 4-4, 4-7, Glos-5-Glos-9, Glos-11,
                                          Glos-12, Glos-14, Glos-16, Glos-20,
                                          Glos-22, Bib-6, Bib-7, A-1-C-3
Environmental.............................3-11, 4-1, 4-2, B-1, D-3
EPL.......................................4-6, Glos-11, Glos-25
Evaluated Products List...................4-6, Glos-11, Glos-25
Executive Order...........................Glos-21, A-1, G-10
Exemption.................................3-10, C-1
Facility..................................1-5, 2-4, 2-8, 2-9, 3-4-3-6, 3-9, 3-12, 4-1,
                                          4-2, 4-7, Glos-19, Bib-6, Bib-7, Bib-9
Facsimile.................................4-13
FAX.......................................4-13, G-1
Federal Bureau of Investigation...........III, Bib-6, A-1
Federal Managers' Financial Integrity Act.G-1, G-5, G-7, G-9, G-19, G-20, G-26
Firewalls.................................Bib-1, Bib-3, G-28, G-30
FMFIA.....................................Bib-6, G-1, G-6, G-9, G-19, G-21, G-31
FOIA......................................1-3, 1-5, 4-9, Bib-3, Bib-9, A-1
Freedom of Information....................1-3, 1-5, 4-9, Glos-22, Bib-2, Bib-3, Bib-9, A-1
General Accounting Office.................A-1, G-3, G-11
General Support System....................3-4, 3-10, Glos-12, D-2, G-17-G-19, G-22-G-25, G-27, G-28
Government Corporation and Control Act....G-16
Government Performance and Results Act....G-2, G-9, G-13
IG........................................G-2, G-3, G-5, G-11-G-15
Incident Response Capability..............Bib-9, G-18, G-25
Individual Accountability.................G-19, G-24, G-25, G-28, G-29
Information Sharing.......................G-20, G-28
Inspector General.........................G-2, G-10
Internal Affairs..........................2-5, 2-7, 5-1
Internal Controls.........................G-3, G-7, G-10, G-11, G-13
Internet..................................III, 4-13, Glos-14, Glos-26, Bib-1-Bib-3, G-1, G-8, G-24, G-30
IRM.......................................1-3-2-5, 3-9, 3-10, 3-12, Bib-3, A-1, G-13, G-18, G-19
Labels....................................4-11
Least Privilege...........................4-4, Glos-15, G-19, G-25, G-29
License...................................4-9, 4-13
Life-Cycle................................1-3, 2-8, 3-12, 4-6, Glos-7, Glos-10, Glos-13, Glos-20
Maintenance...............................1-3, 2-8, 3-3, 3-11, 4-3, 4-9-Glos-11, Glos-13, G-25
Major Application.........................2-5, 3-7, Glos-2, Glos-15, D-2, G-17, G-19, G-22, G-23, G-27-G-29
Malicious Code............................4-9, 5-1, Glos-4, Glos-15, Glos-24-Glos-26, B-3
Manual procedures.........................G-25
Material Weakness.........................G-4, G-13, G-14
MISSI.....................................4-4-Glos-6, Glos-11, Glos-12, Glos-16
Monitoring................................4-5, 4-7, G-4, G-12, G-14
MOU.......................................2-11, 4-10, 4-13, A-1
National Information Infrastructure.......4-12, 4-13, A-2, G-30
National Security Agency..................III, Glos-16, Glos-25, A-2, G-30
Networks..................................1-1, 2-1-3-3, 3-8, 4-4, 4-5, 4-12, 4-13,
                                          5-1, Glos-12, Glos-16, Glos-22, C-1
NIST Handbook.............................Bib-5, G-22, G-24
Non-Customs...............................1-1, 4-3, 4-5, 4-11-4-13, 5-1
Object Reuse..............................4-4, Glos-6, Glos-7, Glos-17, Glos-19, Bib-5, C-2
Office of Management and Budget...........III, 1-1, 1-6, 3-5, A-2, G-1, G-7, G-16, G-17
Office of Personnel Management............III, 1-1, Bib-8, A-2, E-1, G-17, G-21, G-24, G-31
OPM.......................................1-1, Bib-8, A-2, E-1, G-17, G-18, G-20, G-24, G-30, G-31
Orange Book...............................Glos-10, Glos-17, Glos-23, Glos-24, Bib-3, A-2
Oversight.................................III, 1-2-1-4, 2-2, 2-3, 2-5, 3-1, 3-11, 3-12,
                                          Glos-15, Bib-7, G-12, G-15, G-17, G-23
PAA.......................................2-3, 2-5, 4-10, 4-12, Glos-2, Glos-8, Glos-9, Glos-18, A-2
Paperwork Reduction Act...................Bib-7, G-16, G-18, G-19, G-22, G-23, G-31
Password..................................4-4, 4-7, Glos-18, Bib-5, Bib-7, B-2, B-4, C-1,
                                          C-2, G-22, G-24, G-26
PBX.......................................4-14, Glos-18, A-2-B-4
Personally-owned..........................4-12, Glos-18, Bib-9
Physical Security.........................2-9, 3-4, 4-1, Glos-18, Bib-5, Bib-8
Portable..................................4-10, B-1
Principal Accrediting Authority...........2-3, 2-5, 4-10, 4-12, Glos-2, Glos-18, A-2
Privacy Act...............................1-3, 1-5, 2-6, 4-9, 5-1, Glos-18, Glos-21-Glos-23,
                                          Bib-2, Bib-3, Bib-5, Bib-6, A-2
Private Branch Exchange...................Glos-18, A-2, B-3
Process Owner.............................2-5, 3-1, 4-3, Glos-2, Glos-3, Glos-19
Public Access.............................G-20, G-28, G-29
Recovery..................................1-4, 2-5, 3-1-3-4, 3-11, Glos-4, Glos-7,
                                          Glos-10, Glos-19, Glos-23, Bib-5, G-26
Red Book..................................Bib-1
Remanence.................................Glos-6, Glos-17, Glos-19, Bib-1, C-2
Reports...................................Glos-3, B-3-G-6, G-12-G-15, G-21, G-31
Residual Data.............................4-4, 4-10, Glos-17, C-1
Residual Risk.............................2-4, 3-5, 3-9, 3-10, Glos-19
Reuse.....................................4-4, Glos-6, Glos-7, Glos-17, Glos-19, Bib-5, C-2
Risk Analysis.............................3-4-3-6, 4-1, 4-2, 4-4, 4-11, Glos-4, Glos-20, C-2, D-3, G-30
Risk Assessment...........................3-5, Glos-20, Bib-3, C-1-F-2, G-22
Risk Management...........................2-1, 2-4, 3-1, 3-2, 3-4, 3-5, Glos-20, E-3, E-4, F-2, G-22
Rules of Behavior.........................3-11, G-18, G-24, G-26-G-28
Rules of the System.......................3-10, G-18, G-24, G-26
SBU.......................................1-2, 3-8, 4-11, 4-12, Glos-7, Glos-15-Glos-17,
                                          Glos-21, Glos-22, A-2, C-1, C-3, E-2, F-1
SDLC......................................1-5, 2-5-4-6, A-2
Security Controls.........................1-2, 2-10, 4-1, 4-7, 4-9, 4-11, Glos-10, 
                                          Glos-21, B-3, G-18, G-20, G-22-G-24, G-26-G-29
Security Features User's Guide............4-7, A-2
Security Incidents........................2-5, 2-7, 2-9, 5-1, G-21, G-25, G-30
Security Mode.............................3-7-3-9, 4-12, Glos-1, Glos-9, Glos-23
Security Plan.............................2-2, 2-5, 2-9, 3-2, 3-3, 3-9, 3-10, 4-4-4-9,
                                          4-11, D-1, D-2, G-18-G-20, G-23, G-24,
                                          G-26, G-27, G-29
Security Practices........................4-14, B-1, E-5
Security Programs Division................1-5, 2-4, 3-9, 4-1-A-2
Security Staff............................G-27
Sensitive But Unclassified................1-2, 4-11, 4-12, Glos-5, Glos-15, Glos-17,
                                          Glos-21, Glos-22, A-2, F-1
Separation of Duties......................G-3, G-4, G-12, G-19, G-25, G-28
SFUG......................................4-7, A-2
Site......................................2-8, 2-9, 3-4, 4-1, 4-9, 4-10, Glos-22, Bib-3
Skipjack..................................Glos-5, Glos-6, Glos-9, Glos-10, Glos-12, Glos-20, Glos-22
SPD.......................................1-5, 2-4, 3-9, 3-10, 3-12, 4-1-A-2
Steering Committee........................1-3, 2-3, 3-1, 3-11
Strategic IRM Plan........................Bib-3, G-18, G-19
System High Security Mode.................Glos-9, Glos-23
Systems Development Life Cycle............1-5, Bib-2, Bib-3
TCB.......................................Glos-24, F-2
TCSEC.....................................4-3-Glos-5, Glos-7, Glos-8, Glos-10, Glos-17, 
                                          Glos-19, Glos-22-Glos-24, Bib-3, Bib-7, A-2
Telecommunications........................1-3, 1-6, 4-3, 4-12-4-14, Glos-1, Glos-6, Glos-16,
                                          Bib-2, Bib-3, Bib-6, Bib-9, A-2, B-3, C-1, G-31
Tempest...................................1-6, Glos-11, Glos-24
Testing...................................1-3, 3-1, 3-4, 3-7, 3-8, 4-6, Bib-5, C-2-G-4, 
                                          G-26, G-28
TFM.......................................4-7, A-2
Trade Community...........................III, 1-1, 1-2, 1-4, 2-11, 2-12, 4-3, 4-8, Glos-3
Training..................................1-4, 2-2, 2-3, 2-7, 2-10-2-12, 3-1, 3-10-3-12, 4-3,
                                          Bib-2, Bib-6, Bib-8, D-3, E-1-E-3, G-18-	G-21, 
                                          G-24, G-25, G-28, G-30, G-31
Trojan Horse..............................Glos-4, Glos-15, Glos-24
Trusted Computer Base.....................Glos-24, F-2
Trusted Computer System
   Evaluation Criteria....................4-3, 4-4, Glos-10, Glos-17, Glos-19, Glos-23,
                                          Bib-3, Bib-6-Bib-8, A-2
Trusted Facility Manual...................4-7
Vendor....................................4-5, 4-6, B-2
Violations................................1-2, 2-5, 5-1, E-3, E-5, F-1
Virus.....................................2-5, 2-7, 4-9, 5-1, Glos-4, Glos-15,
                                          Glos-25, Bib-8, Bib-9, B-3, G-26
Vital Records.............................Glos-11, Glos-20, Glos-25
Voice.....................................1-3-4-4, 4-14, B-3, B-4
Waiver....................................3-10, 4-1, 4-3, 4-12
Warning Banner............................4-4, 4-5
Work at Home..............................4-11, G-24
World Wide Web............................III, Glos-26, A-2, G-1, G-8, G-29
Worm......................................Glos-4, Glos-15, Glos-26

Reader's Comment Form

Title: AUTOMATED INFORMATION SYSTEMS SECURITY POLICY MANUAL

CIS HB 1400-04

U.S. Customs Service

Office of Information and Technology

Automated Information Systems Security Division

Attention: Mr. Tom Bovasso or AIS Security Administration.

Dear Reader:

You may use this form to communicate your comments about this publication, its organization, or subject matter with the understanding that the U.S. Customs Service may use or distribute whatever information you supply in any way it believes appropriate without incurring any obligation to you. Thank you for your cooperation.