Attachment J - DHS Mgmt Directive-4300A-policy.pdf

DHS Sensitive Systems Policy

Directive 4300A

INFORMATION TECHNOLOGY SECURITY PROGRAM

Version 5.5

September 30, 2007

This implements DHS Management Directive 4300.1

DEPARTMENT OF HOMELAND SECURITY

DHS SENSITIVE SYSTEMS POLICY DIRECTIVE 4300A

DOCUMENT CHANGE HISTORY

Version Date Description

0.1 December 13, 2002 Draft Baseline Release

0.2 December 30, 2002 Revised Draft

0.5 January 27, 2003 Day One Interim Policy

1.0 June 1, 2003 Department Policy

1.1 December 3, 2003 Updated Department Policy

2.0 March 31, 2004 Content Update

2.1 July 26, 2004 Content Update

2.2 February 28, 2005 Content Update

2.3 March 7, 2005 Content Update

3.0 March 31, 2005 Includes updates to PKI, Wireless Communications, and Media Sanitization (now Media Reuse and Disposition) sections

3.1 July 29, 2005 New policies: 3.1b,e,f, 3.1g. 4.1.5b, 4.8.4a.

Modified policies: 3.7b, c, 3.9b,g, 3.10a, 4.3.1b, 4.8.2a, 4.8.5e, 5.1.1b, 5.2.2a, 5.3a, c, 5.4.1a, 5.4.5d, 5.4.8c, 5.5.1a, 5.7d. Policies relating to media disposal incorporated into policies within Media Reuse and Disposition section. Deleted policy regarding use of automated DHS tool for conducting vulnerability assessments.

3.2 October 1, 2005 Modified policies 3.8b, 4.8.1a, 5.2.1a&b, 5.2.2a, and 5.4.3c; combined (with modifications) policies 4.1e and 4.1f; modified Section 1.5

3.3 December 30, 2005 New policies: policies 3.9a–d; 3.11.1b; 4.3.1a; 4.6c;

5.4.3d&e. Modified policies: policies 3.9i&j;

4.3.2a; 4.6a, b; 4.6.1e; 4.6.2j; 4.6.2.1a; 4.6.3e;

5.4.3c; 5.5.2k. Modified sections: 2.5, 2.7, 2.9, 2.11, 3.9, 5.5.2.

4.0 June 1, 2006 New policies: 3.5.3.c&g, 4.6.2.3.c, 5.1.c, 5.2.c, 5.4.1.a. Modified policies: 3.5.1.c, 3.5.3.d–f, 3.7.a&b, 3.9.a&b, d, 4.1.4.b&c, 4.2.1.a, 4.3.1.a, 4.6.c, 4.6.1.a, 4.6.2.f, 4.10.3.a, 5.2.1.b, 5.3.a&b, 5.4.1.b, 5.4.3.c, 5.4.5.d. Modified section: Section 2.9.

4.1 September 8, 2006 New policies: 3.14.1.a–c; 3.14.3.a–c; 4.10.1.c;

v5.5, September 30, 2007 i

5.3.d&e; 5.4.1.c–e. Modified policies: 3.9.b;

4.6.2.d; 4.8.2.a–c; 4.10.1.b; 5.1.c; 5.3.c; 5.4.1.b.

New sections: 3.14, 3.14.1, 3.14.3. Modified sections: 2.9, 4.8.2.

4.2 September 29, 2006 New policies: 4.6.4.a–f. Modified policies:

4.3.3.a–c. New section: 4.6.4.

5.0 March 1, 2007 New policies: 4.1.5.h. Modified policies: 3.10.c, 4.1.1.d, 4.1.5.a,b,f, &g, 4.6.2.d, 4.6.3.f, 5.2.c, 5.4.8.a, 5.6.b. New sections: 4.1.1. Modified sections: 1.2, 1.4.2, 1.4.3, 2.9, 3.12, 4.1 and subsections, 4.6.1– 4.6.4, 4.9, 5.2.1. Renumbered sections: 4.1.2–4.1.6, 4.9, 4.10, 4.11, 4.12.

5.1 April 18, 2007 Update based on SOC CONOPS, Final Version

1.4.1, April 6, 2007; Adds DHS Chief Financial Officer – Designated Financial Systems; Updates the term, Sensitive But Unclassified to For Official Use Only

5.2 June 1, 2007 Updates Sections 2.7, 2.9, 2.12, 3.3, 3.5.1, 3.5.3, 3.6, 3.8, 3.9, 3.10, 3.14, 3.15, 4.1.5, 4.1.6, 4.10, 4.12, 5.1.1, 5.2, 5.3, 5.4.1, 5.4.3, 5.4.4, 5.4.8, 5.5.1, 5.7

5.3 August 3, 2007 Revised policy in Sections 3.5.1 and 5.5.1, and removed Section 3.5.2. Removed Sections 3.11.2 and 3.11.4

5.4 October 1, 2007 Content update, incorporation of change requests

5.5 September 30, 2007 Section 1.0: 1.1 – Added text regarding policy implementation and DHS security compliance tool updates. 1.2 – Removed two references from list;

deleted "various" from citation of standards.

Section 2.0: 2.0 – Insert the following after the first sentence in the second paragraph: “Security is an inherently governmental responsibility. Contractors and other sources may assist in the performance of security functions, but a government individual must always be designated as the responsible agent for all security requirements and functions.” 2.3 – Removed parentheses from "in writing."

Section 3.0: 3.9 – Inserted new policy element “l” regarding CISO concurrence for accreditation. 3.15

– Added text regarding Component CFOs and ISSMs.

v5.5, September 30, 2007 ii

Section 4.0: 4.1.1 – Capitalized “Background,” and added "(BI)." 4.3.1 – Two new elements were added to the policy table. 4.7 – Inserted "where required or appropriate" before the sentence. 4.8.3 – Title changed to “Personally Owned Equipment and Software (not owned by or contracted for by the Government).” 4.8.6 – Included new section regarding wireless settings for peripheral equipment.

Section 5.0: 5.1c – Changed inactive accounts to “disable user identifiers after 45 days of inactivity.”

5.1.1 – First sentence of the second paragraph was rewritten to prohibit use of personal passwords by multiple individuals. 5.2.2 – Title changed to “Automatic Session Termination.”

v5.5, September 30, 2007 iii

TABLE OF CONTENTS

1.0 INTRODUCTION

1.1 IT Security Program Policy

1.2 Authorities

1.3 Policy Overview

1.4 Definitions

1.4.1 Classified National Security Information

1.4.2 National Security Information

1.4.3 Sensitive Information

1.4.4 Public Information

1.4.5 Information Technology (IT)

1.4.6 DHS IT System

1.4.6.1 General Support System (GSS)

1.4.6.2 Major Application (MA)

1.4.7 Component

1.4.8 Trust Domain

1.4.9 Operational Data

1.5 Waivers and Exceptions

1.6 Information Sharing and Communication Strategy

2.0 ROLES AND RESPONSIBILITIES

2.1 Secretary of Homeland Security

2.2 Under Secretaries and Heads of DHS Components

2.3 DHS Chief Information Officer (CIO)

2.4 Component Chief Information Officers

2.5 Chief Information Security Officer (CISO)

2.6 Office of the Chief Privacy Officer (CPO)

2.7 DHS Chief Security Officer (CSO)

2.8 Component Information Systems Security Manager (ISSM)

2.9 Component Privacy Offices and Privacy Points of Contact (PPOC)

2.10 Program Managers (PM)

2.11 United States Computer Emergency Readiness Team (US-CERT)

2.12 Certifying Official

2.13 Designated Accrediting Authority (DAA)

2.14 Information Systems Security Officer (ISSO)

2.15 System Owners

2.16 Users of DHS Supplied Computing Resources

2.17 Additional Personnel

2.18 DHS Chief Financial Officer designated Financial Systems

2.18.1 DHS CFO

2.18.2 DHS CIO

2.18.3 Component CFO

2.18.4 Component CIO

2.18.5 System Owners

3.0 MANAGEMENT POLICIES

3.1 Basic Requirements

v5.5, September 30, 2007 iv

3.2 Capital Planning and Investment Control

3.3 Contractors and Outsourced Operations

3.4 Performance Measures and Metrics

3.5 Continuity Planning for Critical DHS Assets

3.5.1 Continuity of Operations Planning (COOP)

3.5.2 IT Contingency Planning (CP)

3.6 System Development Life Cycle

3.7 Configuration Management

3.8 Risk Management

3.9 Certification and Accreditation, Remediation, and Reporting

3.10 IT Security Review and Assistance

3.11 Security Working Groups and Forums

3.11.1 DHS Information Systems Security Board

3.11.2 DHS IT Security Training Working Group

3.11.3 DHS Wireless Security Working Group (WSWG)

3.12 IT Security Policy Violation and Disciplinary Action

3.13 Required Reporting

3.14 Privacy and Data Security

3.14.1 Personally Identifiable Information (PII)

3.14.2 Privacy Impact Assessments

3.14.3 Privacy Incident Reporting

3.14.4 E-Authentication

3.15 DHS Chief Financial Officer Designated Financial Systems

4.0 OPERATIONAL POLICIES

4.1 Personnel

4.1.1 Citizenship, Personnel Screening, and Position Categorization

4.1.2 Rules of Behavior

4.1.3 Access to Sensitive Information

4.1.4 Separation of Duties

4.1.5 IT Security Awareness, Training, and Education

4.1.6 Separation from Duty

4.2 IT Physical Security

4.2.1 General Physical Access

4.2.2 Sensitive Facility

4.3 Media Controls

4.3.1 Media Protection

4.3.2 Media Marking

4.3.3 Media Sanitization and Disposal

4.3.4 Production, Input/Output Controls

4.4 Voice Communications Security

4.4.1 Private Branch Exchange

4.4.2 Telephone Communications

4.4.3 Voice Mail

4.5 Data Communications

4.5.1 Telecommunications Protection Techniques

4.5.2 Facsimiles

v5.5, September 30, 2007 v

4.5.3 Video Teleconferencing

4.5.4 Voice over Data Networks

4.6 Wireless Communications

4.6.1 Wireless Systems

4.6.2 Wireless Portable Electronic Devices (PED)

4.6.2.1 Cellular Phones

4.6.2.2 Pagers

4.6.2.3 Multifunctional Wireless Devices

4.6.3 Wireless Tactical Systems

4.6.4 Radio Frequency Identification (RFID)

4.7 Overseas Communications

4.8 Equipment

4.8.1 Workstations

4.8.2 Laptop Computers and Other Mobile Computing Devices

4.8.3 Personally Owned Equipment and Software (Not owned by or contracted for by the Government)

4.8.4 Hardware and Software

4.8.5 Personal Use of Government Office Equipment and DHS IT

Systems/Computers

4.8.6 Wireless Settings for Peripheral Equipment

4.9 Security Incidents and Incident Response and Reporting

4.9.1 Law Enforcement Incident Response

4.10 Documentation (Manuals, Network Diagrams)

4.11 Information and Data Backup

4.12 Converging Technologies

5.0 TECHNICAL POLICIES

5.1 Identification and Authentication

5.1.1 Passwords

5.2 Access Control

5.2.1 Automatic Account Lockout

5.2.2 Automatic Session Termination

5.2.3 Warning Banner

5.3 Auditing

5.4 Network and Communications Security

5.4.1 Remote Access and Dial-In

5.4.2 Network Security Monitoring

5.4.3 Network Connectivity

5.4.4 Firewalls

5.4.5 Internet Security

5.4.6 Email Security

5.4.7 Personal Email Accounts

5.4.8 Testing and Vulnerability Management

5.4.9 Peer-to-Peer Technology

5.5 Cryptography

5.5.1 Encryption

5.5.2 Public Key Infrastructure

v5.5, September 30, 2007 vi

5.5.3 Public Key/Private Key

5.6 Virus Protection

5.7 Product Assurance

6.0 DOCUMENT CHANGE REQUESTS

7.0 QUESTIONS AND COMMENTS

v5.5, September 30, 2007 vii

1.0 INTRODUCTION

This document articulates the Department of Homeland Security (DHS) Information Technology (IT) Security Program policies for sensitive systems. Procedures for implementing these policies are outlined in a companion publication: DHS 4300A Sensitive Systems Handbook. The handbook serves as a foundation for Components to develop and implement their IT security programs. The baseline security requirements (BLSRs) included in the handbook must be addressed when developing IT security documents.

1.1 IT Security Program Policy

The DHS IT Security Program provides a baseline of policies, standards, and guidelines for DHS Components. This document provides direction to managers and senior executives for managing and protecting sensitive systems. It also outlines policies relating to management, operational, and technical controls necessary for ensuring confidentiality, integrity, availability, authenticity, and nonrepudiation within the DHS IT infrastructure and operations.

The policies and direction contained in this document apply to all DHS Components. IT security policies and implementing procedures for National Security Systems are covered in DHS National Security Systems Policy Directive 4300B and DHS 4300B National Security Systems Handbook.

The DHS IT Security Program does not apply to systems that process, store, or transmit National Intelligence Information.

Policy elements are effective when issued. Any policy elements that have not been implemented within 90 days shall be considered a weakness. Either a system or program POA&M must be generated by the Component for the identified weaknesses. When DHS Security Compliance tools (RMS and TAF) are required to be updated to reflect policy element changes, tool changes shall be available to the Department within 45 days of the policy changes.

1.2 Authorities

The DHS has established a Department-wide IT security program and organization based on the following Executive orders, public laws, and national policy:

• Federal Information Security Management Act (FISMA) of 2002, November 25, 2002

• Federal Financial Management Improvement Act of 1996 (FFMIA), P.L. 104-208

• Federal Managers’ Financial Integrity Act of 1982 (FMFIA), P.L. 97-255

• The National Security Act of 1947, dated July 26, 1947

• Privacy Act of 1974, As Amended. 5 United States Code (U.S.C.) 552a, Public Law 93-579, Washington, D.C., July 14, 1987

• Public Law 104-106, Clinger-Cohen Act of 1996 [formerly, Information Technology Management Reform Act (ITMRA)], February 10, 1996

• Public Law 107-296, Homeland Security Act of 2002 v5.5, September 30, 2007 1

• 5 Code of Federal Regulations (CFR) §2635, Office of Government Ethics, Standards of Ethical Conduct for Employees of the Executive Branch

• Executive Order 12472, Assignment of National Security and Emergency Preparedness Telecommunications Functions, dated April 3, 1984

• Executive Order 12656, Assignment of Emergency Preparedness Responsibilities, dated November 18, 1988, as amended

• Homeland Security Presidential Directive 12, Policy for a Common Identification Standard for Federal Employees and Contractors, August 27, 2004

• Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources

• OMB Circular A123, Management’s Responsibility for Internal Control, Revised, December 21, 2004

• OMB Circular A-127, Financial Management Systems, Revised December 1, 2004

• OMB Bulletin 06-03, Audit Requirements for Federal Financial Statements August 23, 2006

• Department of Homeland Security Acquisition Regulation (HSAR), June 2006

• DHS Management Directives (e.g., MD 0470.1, MD 1030, MD 4400.1, MD 4500.1, MD

4600.1, MD 11042.1, MD 11050.2)

• National Institute of Standards and Technology (NIST) Special Publications (e.g., 800-16, 800-34, 800-37, 800-50, 800-53) and Federal Information Processing Standards (FIPS) (e.g., FIPS 199, 200)

• Department of State 12 Foreign Affairs Manual (FAM) 600, Information Security Technology, June 22, 2000

1.3 Policy Overview

DHS IT security policies delineate the security management structure and foundation to measure progress and compliance. Policies in this document are organized under three areas:

management, operational, and technical.

• Management Controls – Focus on managing both the IT security system and system risk.

These controls consist of risk mitigation techniques and concerns normally addressed by management.

• Operational Controls – Focus on mechanisms primarily implemented and executed by people. These controls are designed to improve the security of a particular system, or group of systems. These controls require technical or specialized expertise and often rely on management and technical controls.

• Technical Controls – Focus on security controls executed by IT systems. These controls provide automated protection from unauthorized access or misuse. They facilitate detection of security violations, and support security requirements for applications and data.

v5.5, September 30, 2007 2

1.4 Definitions

The following definitions apply to the policies and procedures outlined in this document. Other definitions may be found in the National InfoSec Glossary (http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf).

1.4.1 Classified National Security Information

Information that has been determined, pursuant to Executive Order 12958, as amended, or any predecessor order, to require protection against unauthorized disclosure and is marked to indicate its classified status.

1.4.2 National Security Information

Information that has been determined, pursuant to Executive Order 12958 (as amended) or any predecessor order, to require protection against unauthorized disclosure.

1.4.3 Sensitive Information

“Sensitive information” is information not otherwise categorized by statute or regulation that if disclosed could have an adverse impact on the welfare or privacy of individuals or on the welfare or conduct of Federal programs or other programs or operations essential to the national interest.

Examples of sensitive information include personal data such as Social Security Number; trade secrets; system vulnerability information; pre-solicitation procurement documents, such as statements of work; and law enforcement investigative methods; similarly, detailed reports related to computer security deficiencies in internal controls are also sensitive information because of the potential damage that could be caused by the misuse of this information. This type of information concerning financial systems will be identified as Sensitive Financial Information, if on another system it would be identified as system vulnerability information. All sensitive information must be protected from loss, misuse, modification, and unauthorized access.

With the exception of certain types of information protected by statute (e.g. Sensitive Security Information, Critical Infrastructure Information), there are no specific Federal criteria and no standard terminology for designating types of sensitive information. Such designations are left to the discretion of each individual Federal agency. “For Official Use Only” (FOUO) is the term used within DHS to identify unclassified information of a sensitive nature that is not otherwise categorized by statute or regulation.

1.4.4 Public Information

This type of information can be disclosed to the public without restriction but requires protection against erroneous manipulation or alteration. (e.g. Public Web sites)

1.4.5 Information Technology (IT)

The Clinger-Cohen Act defines information technology as any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by an Executive agency.

For purposes of the preceding definition, “equipment” refers to that used by any DHS Component or contractor, if the contractor requires the use of such equipment in the performance of a service or the furnishing of a product.

v5.5, September 30, 2007 3 http://www.cnss.gov/Assets/pdf/cnssi_4009.pdf

The term “information technology” includes computers, ancillary equipment, software, firmware, and similar procedures, services (including support services), and related resources.

1.4.6 DHS IT System

A DHS system is any IT that is (1) owned, leased, or operated by any DHS Component, (2) operated by a contractor on behalf of DHS, or (3) operated by another Federal, state, or local Government agency on behalf of DHS. DHS systems include general support systems and major applications.

1.4.6.1 General Support System (GSS)

A general support system (GSS) is an interconnected set of information resources under the same direct management control that share common functionality. A GSS normally includes hardware, software, applications, data and users. Examples of a GSS include a local area network (LAN), an agencywide backbone, a communications network, a data processing center, a tactical radio network, or a shared information processing service organization.

1.4.6.2 Major Application (MA)

A major application (MA) is an automated information system (AIS) that “requires special 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.1” An MA is distinguishable from a GSS by the fact that it is a discrete application, whereas a GSS may support multiple applications.

1.4.7 Component

A DHS Component is any of the entities within DHS, including all DHS offices and independent agencies.

1.4.8 Trust Domain

A Trust Domain consists of a group of people, information resources, data systems, and/or networks subject to a shared security policy (set of rules governing access to data and services).

(For example, a Trust Domain may be set up between different network segments that require specific usage policies based on information processed, such as law enforcement information.

1.4.9 Operational Data

Operational data is information used in the execution of any DHS mission.

1.5 Waivers and Exceptions

Components may request waivers to, or exceptions from, any portion of this policy, for up to 6 (six) months, whenever they are unable to fully comply with policy requirements. Requests are made, through the Information Systems Security Board (ISSB), to the Chief Information Security Officer (CISO) and shall include the operational justification, risk acceptance, risk mitigation measures, and a plan for bringing the system into compliance. A second waiver request for up to 6 (six) months may be made only by the Head of the Component and only if the waiver is reported as a material weakness in the Component’s Federal Information Systems Management Act (FISMA) report.

1 OMB Circular A-130 v5.5, September 30, 2007 4

A Component may request an Exception to Policy whenever it is unable to bring the system into compliance. Exceptions are generally limited to mission-specific systems that are not part of the DHS Enterprise Infrastructure. This request is made, through the ISSB, to the CISO and shall include the operational justification, risk acceptance, and risk mitigation measures.

The Waiver Request Form, located in Attachment B of the DHS 4300A Sensitive Systems Handbook, shall be used.

NOTE: Special procedures apply for exception to the requirement that persons accessing DHS systems be U.S. Citizens (policy 4.1e). Under normal conditions, only U.S. Citizens are allowed access to DHS systems and networks, however, at times there is a need to grant access to foreign nationals. Access for foreign nationals is normally a long-term commitment, and exceptions to appropriate policies are treated separately from standard exceptions and waivers. The approval chain for an exception to the U.S. Citizenship requirement flows through the Component Head, the Office of Security, and the Chief Information Officer. Attachment J to the DHS 4300A Sensitive Systems Handbook provides an electronic form for requesting exceptions to the U.S.

Citizenship requirement.

1.6 Information Sharing and Communication Strategy

The DHS SOC exchanges information with Component SOCs, NOCs, the HSDN SOC, the Intelligence Community, and with external organizations in order to facilitate the security and operation of the DHS network. This exchange enhances situational awareness and provides a common operating picture to network managers. The operating picture is developed from information obtained from “raw” fault, configuration management, accounting, performance, and security data. This data is monitored, collected, analyzed, processed, and reported by the NOCs and SOCs.

The DHS SOC is responsible for communicating other information such as incident reports, notifications, vulnerability alerts and operational statuses to the Component SOCs, ISSMs or other identified Component points of contact.

The DHS SOC portal implements role-based user profiles that allow Components to use the website’s incident database capabilities. Users assigned to Component groups will be able to perform actions such as:

• Entering incident information into the DHS SOC incident database

• Generating preformatted incident reports

• Initiating queries of the incident database

• Viewing FISMA incident reporting numbers

• Automating portions of the Information Security Vulnerability Management (ISVM) program

• Automating portions of the vulnerability assessment program v5.5, September 30, 2007 5

2.0 ROLES AND RESPONSIBILITIES

Persons and organizations must understand their roles and responsibilities and adhere to all relevant Federal and Departmental regulations and guidance.

Designated personnel play a major role in the planning and implementation of IT security requirements. Security is an inherently governmental responsibility. Contractors and other sources may assist in the performance of security functions, but a government individual must always be designated as the responsible agent for all security requirements and functions. The following presents a list of roles and responsibilities for implementing these requirements.

2.1 Secretary of Homeland Security

The Secretary of Homeland Security is responsible for ensuring that DHS IT systems and their data are protected in accordance with Congressional and Presidential directives. To that end, the Secretary:

• Ensures the integrity, confidentiality, availability, authenticity, and nonrepudiation of information and information systems.

• Ensures that DHS implements its IT Security Program throughout the life cycle of each DHS system.

• Submits (1) the Chief Information Officer’s assessment of the adequacy and effectiveness of the Department’s information security procedures, practices, and FISMA compliance, and (2) the results of an independent information security program evaluation performed by the DHS Inspector General, annually to the Director of the Office of Management and Budget (OMB)

2.2 Under Secretaries and Heads of DHS Components

The Under Secretaries and the heads of DHS Components:

• Appoint Chief Information Officers (CIO) and Information System Security Managers (ISSM) as appropriate.

• Ensure that an IT Security Program is established and managed in accordance with DHS policy and implementation directives.

• Ensure that the security of IT systems is an integral part of the life cycle management process for all IT systems developed and maintained within their Components.

• Ensure that adequate funding for IT security is provided for Component IT systems and that adequate funding requirements are included for all IT systems budgets.

• Ensure that IT system data are entered into the appropriate DHS Security Management Tools to support DHS IT security oversight and FISMA reporting requirements.

• Ensure that the requirements for an IT security performance metrics program are implemented.

2.3 DHS Chief Information Officer (CIO)

The DHS Chief Information Officer (CIO) will establish and oversee the Department-wide IT Security Program, ensure proper computer security incident response, and provide consulting assistance to all DHS offices for their individual programs. The DHS CIO provides management v5.5, September 30, 2007 6 direction for the DHS Security Operatons Center (SOC) and overall direction for Component SOCs. The DHS CIO, or designated representative, has the sole responsibility for public release of information concerning computer security incidents. The CIO will consult with the DHS Privacy Office and Public Affairs Office prior to releasing any information.

The DHS CIO:

• Appoints a Federal employee in writing to serve as the DHS Chief Information Security Officer (CISO).

• Serves as the Designated Accrediting Authority (DAA) for DHS enterprise IT systems. This responsibility may be delegated in writing as appropriate.

• Participates in developing DHS performance plans, including descriptions of the time periods and budget, staffing, and training resources required to implement the Department-wide security program.

• Ensures that all IT systems acquisition documents, including existing contracts, include appropriate IT security requirements and comply with DHS IT security policies.

• Ensures that DHS security programs integrate fully into the DHS enterprise architecture and capital planning and investment control processes.

• Ensures that system owners understand and appropriately address risks, including interconnectivity with other programs and systems outside their control.

• Reviews and evaluates the IT Security Program annually.

• Ensures that an IT security performance metrics program is developed, implemented, and funded.

• Reports to the Under Secretary for Management on matters relating to the security of DHS IT systems.

2.4 Component Chief Information Officers

Component CIOs provide management direction to their security operations and are the principal advocates for computer security incident response.

Component Chief Information Officers (CIO):

• Establish and oversee their Component IT security programs.

• Ensure that a Component Information System Security Manager (ISSM) has been appointed.

• Ensure that a Designated Accrediting Authority (DAA) has been appointed for all Component IT systems and serve as the DAA for any IT system where a DAA has not been appointed or where a vacancy exists.

• Ensure that IT security concerns are addressed by Component Configuration Control Boards, Architecture Review Board, and Investment Review Board.

• Ensure that an accurate IT systems inventory is established and maintained.

• Ensure that an IT security performance metrics program is developed, implemented, and funded.

v5.5, September 30, 2007 7

• Advise the DHS CIO of any issues regarding infrastructure protection, vulnerabilities or issues that may cause public concern or loss of credibility.

• Ensure that incidents are reported to the DHS SOC within reporting time requirements as defined in Attachment F of the DHS Sensitive Systems Handbook

• Work with the DHS CIO and Public Affairs Office in preparation for public release of security incident information. The DHS CIO, or designated representative, has sole responsibility for public release of security incident information.

2.5 Chief Information Security Officer (CISO)

The Chief Information Security Officer (CISO) reports directly to the CIO, serves as the Department-wide Information Systems Security Manager (ISSM), and is the principal advisor for IT security matters.

The CISO:

• Issues Department-wide IT security policy, guidance, and architecture requirements for all DHS IT systems and networks

• Implements and manages the Department-wide IT Security Program and ensure compliance with FISMA and OMB requirements.

• Serves as the principal Departmental liaison with organizations outside the DHS for matters relating to IT security.

• Reviews and approves the tools, techniques, and methodologies planned for use in certifying and accrediting DHS IT systems. This includes Security Test and Evaluation (ST&E) plans, contingency plans, and risk assessments.

• Reviews requests for waivers and exception to DHS IT security policy.

• Consults with the DHS Chief Security Officer on matters pertaining to physical security, personnel security, information security, investigations, and SCI systems, as they relate to IT security and infrastructure.

• Briefs the DHS CIO and senior management on the status and outcome of ongoing and completed computer security incidents.

• Tests and evaluates periodically the effectiveness of information security policies, procedures, and practices.

• Develops and implements procedures for detecting, reporting, and responding to computer security incidents.

• Ensures preparation and maintenance of plans and procedures to provide continuity of operations for information systems.

2.6 Office of the Chief Privacy Officer (CPO)

The Chief Privacy Officer (CPO) is responsible for Departmental compliance with privacy policy, including measures for securing information security assets and activities. The CPO works to maintain privacy requirements, while supporting security requirements.

The CPO serves as the senior official responsible for:

v5.5, September 30, 2007 8

• Oversight of privacy incident management

• Responding to suspected or confirmed privacy incidents or incidents involving Personally Identifiable Information (PII)

• Coordinating with the DHS CIO and senior management when dealing with high-impact privacy incidents

• Providing the status and outcomes of ongoing and completed privacy incidents

• Distributing reports to the DHS and Component CIOs

• Receiving reports that impact DHS privacy programs

• Working with the DHS CIO and DHS CISO in preparation for release of computer security incident information involving PII or other privacy issues

• Convening and chairing incident response teams, such as the Privacy Incident Response Team (PIRT) and the Core Management Group (CMG)

2.7 DHS Chief Security Officer (CSO)

The Chief Security Officer (CSO) reports directly to the Deputy Secretary on all matters pertaining to security within the DHS. Pursuant to Executive Order 12958, as amended, the CSO is designated the Senior Agency Official. In that capacity, the CSO:

• Directs and administers the Department’s program under which information is classified, safeguarded, and declassified.

• Coordinates the Department’s classification management program and serve as the DHS point of contact with the Information Security Oversight Office.

• Provides support and coordinates with the Department’s emergency planning and response efforts and activities.

• Provides guidance and oversight on meeting physical security requirements.

2.8 Component Information Systems Security Manager (ISSM)

The Information Systems Security Manager (ISSM) are the principal interface between the Office of the CISO, Component Information Systems Security Officers (ISSOs) and other security practitioners. As such, the ISSM plays a critical role in ensuring that the DHS IT Security Program is implemented and maintained throughout the Component. The ISSM must be a DHS employee and must be appointed by the appropriate Component executive.

ISSMs:

• Oversee the Component IT security program.

• Ensure that IT security-related decisions and information, including updates to the 4300 series of IT security publications, are distributed to the ISSOs and other appropriate persons within their Component.

• Ensure that the Component CIO is kept apprised of all pertinent matters involving the security of IT systems.

• Approve and/or validate all Component IT system security reporting.

v5.5, September 30, 2007 9

• Consult with the Component Privacy Office or Privacy Point of Contact (PPOC) for reporting and handling of privacy incidents.

• Manage IT security resources including oversight and review of Exhibit 300 funding documents.

• Review and approve the security of hardware and software prior to implementation into the Component SOC.

• Test the security of implemented systems

• Implement and manage the Plan of Action and Milestones (POA&M) process.

• Maintain an inventory of all IT systems.

• Ensure the Component IT security program is structured to support DHS and appropriate FISMA and OMB requirements.

• Develop and publish procedures necessary to implement the requirements of DHS IT security policy within the appropriate Component.

• Ensure that Information Systems Security Officers (ISSO) are appointed for each IT system managed at the Component level.

• Review and approve ISSO appointments.

• Ensure that the CISO-approved Risk Management System (RMS) automated tool is utilized for conducting certification and accreditation evaluations.

• Ensure that the CISO-approved Trusted Agent FISMA (TAF) automated tool is utilized for conducting self-assessment evaluations and for reporting required IT security program status information.

• Ensure that weekly incident reports are submitted to the DHS SOC.

• Acknowledge receipt of Information Security Vulnerability Management (ISVM) messages, report compliance with requirements or notify the granting of waivers.

2.9 Component Privacy Offices and Privacy Points of Contact (PPOC)

The Component Privacy Offices and Privacy Points of Contact (PPOC) are responsible for compliance with Federal laws and DHS privacy policy at the Component level. The Privacy Officers and PPOCs work with the Component CIO and DHS CPO to maintain privacy requirements. SOCs will work with their Component Privacy Offices, PPOCs, or with the DHS CPO to address suspected or confirmed privacy incidents (PI) or incidents involving PII.

Component Privacy Offices and Privacy Points of Contact:

• Advise the Component CIO and management regarding privacy issues relevant to the Component.

• Receive and evaluate reports that impact DHS privacy programs.

• Work with system owners to complete privacy impact assessments

• Coordinate with program managers, Component ISSMs, CSIRC, or SOC in evaluating and reporting suspected or confirmed incidents involving PII.

v5.5, September 30, 2007 10

• Inform the DHS CPO of the status of ongoing and completed privacy incidents in a timely manner.

• Advise the CPO regarding the handling of reported privacy Incidents.

• Provide privacy incident updates to US-CERT as further information is obtained.

• Work with the DHS CPO, Component CIO and Component CISO in preparation for release of computer security incident information involving PII or other privacy issues

• Work with the Component CIO and DHS Privacy Officer in preparation for release of computer security incident information involving PII or other privacy issues

2.10 Program Managers (PM)

Program Managers are responsible for ensuring compliance with applicable Federal laws, directives and Departmental policy governing the security, operation, maintenance and privacy protection of IT systems, information and programs under his or her control.

Program Managers:

• Work with system owners, Component ISSMs, and their staffs to ensure information systems are properly secured.

• Understand how to recognize and respond to suspected or confirmed security incidents, privacy incidents or incidents involving PII.

• Consult with Component privacy offices or PPOCs concerning privacy incidents and other privacy issues affecting IT systems and programs under his or her control.

• Prepare and transmit written Privacy Event Notification (PEN) simultaneously to Component privacy offices/PPOCs, the Component CIO and ISSM.

• Supplement privacy incidents reports to the DHS SOC and US-CERT as information becomes available.

2.11 United States Computer Emergency Readiness Team (US-CERT) The United States Computer Emergency Readiness Team (US-CERT) is designated as the central reporting organization within the Federal Government and serves as the central repository for Federal incident data. The DHS SOC will report security incidents to the US-CERT. The US-CERT may notify law enforcement, the Identity Theft Task Force, the Social Security Administration, and the Executive Office of the President, as appropriate.

2.12 Certifying Official

A Certifying Official (typically the ISSM) is assigned to each IT system by an appropriate Component official. A Certifying Official may be responsible for more than one system.

Certifying Officials must be Federal employees and must be designated in writing for each IT system. Designation letters shall be signed by the appropriate Under Secretary or Component Head. The Certifying Official:

• Ensures that required Certification and Accreditation (C&A) activities are completed, and that the test results are documented.

v5.5, September 30, 2007 11

• Ensures that a risk analysis is performed and that it identifies risks, determines their magnitude, and identifies areas needing safeguards.

• Ensures that a system test and evaluation is conducted and the results of such tests are documented or updated annually.

• Ensures that rules of behavior and security procedures/guides are developed.

• Ensures that a contingency plan is prepared and tested annually

• Ensures that the C&A documentation is recorded in the DHS C&A Tool and FISMA Reporting Tool

• Reviews the C&A package (SSP, Security Assessment Report, and POA&M) and recommends to the DAA whether or not the system should be accredited.

• Prepares the security accreditation decision letter for the DAA’s signature.

2.13 Designated Accrediting Authority (DAA)

The Designated Accrediting Authority (DAA) controls personnel, operations, maintenance, and budgets for the systems or field site and has the authority to formally assume responsibility for operating an IT system at an acceptable level of risk. The DAA should control the resources necessary to mitigate risks.

A DAA shall be assigned to each IT system and may be responsible for more than one system.

The DAA should be the system owner or an appropriate program official. (i.e., A Component CFO would be assigned as the DAA for a CFO designated financial system) The Component CIO shall serve as DAA anytime the system owner or an appropriate program official cannot be named.

DAAs:

• Review Notices of Findings and Recommendations (NFR) and Plans of Action and Milestones (POA&M)

• Review and approve corrective actions necessary to mitigate residual risks.

• Approve/disapprove system accreditation, or issue an Interim Authorization to Operate (IATOs may be issued only for systems in development testing or for prototypes).

• Terminate system operation if security conditions warrant such action.

2.14 Information Systems Security Officer (ISSO)

An Information Systems Security Officer (ISSO) shall be appointed in writing, by the appropriate official, for each IT system. An ISSO may either be a Federal employee or an appropriately cleared support contractor and may be assigned to more than one system. For financial or privacy systems, ISSOs shall not be assigned collateral duties.

ISSOs:

• Serve as the principal points of contact for all IT security aspects pertaining to their systems.

• Work closely with the Component ISSM and DHS CISO staff to interpret and apply IT security policies and implementing procedures.

v5.5, September 30, 2007 12

• Serve as liaison between system owners and the ISSM.

• Work with system owners to document weaknesses in POA&Ms and initiate corrective action.

• Employ automated tools (approved by the DHS CISO) such as the Risk Management System (RMS) and Trusted Agent FISMA (TAF).

2.15 System Owners

System owners use information technology to help achieve the mission needs within their program area of responsibility. As such, they are responsible for the successful operation of the IT systems within their program area and are ultimately accountable for the security of the IT systems and programs under their control.

System owners:

• Serve as the Designated Accrediting Authority (DAA) for systems under their purview

• Ensure that an ISSO is formally assigned to each IT system under their control and that this assignment is appropriately documented

• Ensure that required computer security functions and documentation are included in system life cycle planning and budgets

• Work closely with the CIO and other program and IT managers to ensure a complete understanding of risks, especially the increased risks resulting from interconnectivity with other programs and systems

• Document and manage accepted security risks in risk assessments

• Update the security of IT systems within their program area annually

• Ensure that system POA&Ms are prepared and maintained and that points of contact and resources are identified

• Prioritize security weaknesses for mitigation based on material weaknesses, external audits and program assessments

• Work with the Component Privacy Office or PPOC to Conduct Privacy Impact Assessments

(PIA)

• Report Privacy and Computer Security incidents as appropriate, in coordination with the ISSM and Program Manager

2.16 Users of DHS Supplied Computing Resources

DHS employees, contractors, and vendors working on behalf of the DHS or its agencies, are responsible for reporting suspected or confirmed computer security incidents to their Component-level capability, or to the DHS SOC, in accordance with the Component's incident response procedures.

Successful situational awareness depends on effective security awareness and incident handling.

Each Component will review its security awareness training requirements annually to ensure they reflect the evolving and changing nature of incidents.

v5.5, September 30, 2007 13

2.17 Additional Personnel

Other personnel throughout DHS are responsible for various aspects of the IT security program.

Contracting Officers and their Technical Representatives, project managers, system and network administrators, managers, supervisors, and users all play a role in helping to ensure the security of the Department’s IT systems. The DHS 4300A Sensitive Systems Handbook provides a description of the roles and responsibilities of these additional personnel.

In implementing DHS IT security policy, Component heads will include these additional personnel in their security plans.

2.18 DHS Chief Financial Officer designated Financial Systems The DHS CFO-designated financial systems require additional management accountability and effective internal control over financial reporting, as outlined in Section 3.15.

For CFO-designated financial systems, additional roles and responsibilities are summarized in this section.

2.18.1 DHS CFO

The Department CFO oversees application control definitions for financial systems as defined in OMB Bulletin No. 06-03, Audit Requirements for Federal Financial Statements, and DHS Technical Guidance No. 03-06–Laws and Regulations, Cross Servicing Assertion, and Draft OMB Bulletin 01-02. The Department CFO has committed to:

• Identifying financial systems subject to OMB A-123 and Internal Controls over Financial Reporting (ICOFR) requirements (“CFO-designated financial systems”).

• Working with the Department CIO to ensure the confidentiality, integrity and availability of financial data processing.

• Overseeing the development and establishment of policies and procedures regarding automated application controls for Department-wide application software processing financial data.

• Remediating automated application control deficiencies related to financial application policies and procedures at the Department level.

• Tracking and monitoring progress of automated application controls corrective action plans and remediation efforts at the Department and Component Levels.

• Working with the Department CIO to identify and incorporate user requirements for new financial applications or existing Departmental financial applications.

• Working with the DHS CIO to integrate and test the Department-wide business continuity plan.

• Coordinating with the DHS CIO to identify the financial data to be backed up and recovered and developing policies to ensure that procedures are in place for backing up and recovering critical financial data.

v5.5, September 30, 2007 14

2.18.2 DHS CIO

The Department CIO is responsible for overseeing compliance of CFO-designated financial systems with Federal system security regulations and guidelines as documented in DHS Sensitive Systems Policy Directive 4300A, including support for OMB Circular A-123. The Department CIO:

• Ensures sufficient resources are provided to support the Department’s compliance tracking.

• Reviews and evaluates the Department-wide IT Security Program.

• Categorizes information system deficiencies by OMB A-123 information technology general controls (ITGC) domains and TrustedAgent FISMA (TAF) risk levels.

• Remediates Information Technology General Control (ITGC) deficiencies related to policies and procedures at the Department level.

• Tracks and monitors progress of ITGC Plans of Action and Milestones (POA&M) and remediation efforts at the Department and Component levels.

• Ensures that Contracts and Interagency Agreements (IAA) include Homeland Security Acquisition Regulation (HSAR) security clauses.

• Develops Department-wide system development lifecycle methodology and monitor Component compliance with this methodology.

• As part of developing new financial applications or updating existing Departmental applications, integrates CFO feedback to ensure user requirements are adequately addressed.

• Develops and tests Department-wide disaster recovery plan. Coordinate with CFO to incorporate business continuity requirements and test on a periodic basis.

• Based on coordination with Department CFO, develops and implement Department-wide procedures for the routine backing up and recovering of financial data.

2.18.3 Component CFO

The Component CFO, working with the Component system owners, is responsible for overseeing implementation and compliance of IT controls for CFO-designated financial systems at the Component level. The Component CFO:

• Works with the Component CIO and owners of CFO-designated financial systems to help ensure the reliability of financial data processing through Component systems.

• Develops and establishes policies and procedures regarding automated application controls for software processing of financial data.

• Remediates automated application controls deficiencies at the Component level.

• Works with system owners to designate an Information System Security Officer (ISSO) for each of the CFO-designated financial systems, as defined in Section 3.15 of DHS Sensitive Systems Policy Directive 4300A.

v5.5, September 30, 2007 15

• Tracks and monitors progress of automated application controls remediation efforts at the Component level.

• Works with system owners of CFO-designated financial systems to ensure remediation of ITGC deficiencies related to IT policies and procedures.

• Approves accreditation of enterprise CFO-designated financial systems, if not already identified as the Designated Accrediting Authority (DAA). In this role, accept security risk identified during audits of CFO-designated financial systems, on behalf of the Department.

• Works with Component CIO to incorporate user requirements for new financial applications or upgrades to existing financial applications.

• Works with Component CIO to integrate and test Component-wide business continuity plan.

• Coordinates with Component CIOs to identify the financial data needed to be backed up and recovered.

2.18.4 Component CIO

The Component CIO is responsible for overseeing implementation and compliance of CFO-designated financial systems at the Component level. The Component CIO:

• Reviews and evaluates the Component’s CFO-designated financial systems to ensure ITGCs are in place and working effectively.

• Works with the system owners to ensure remediation of ITGC deficiencies related to CFO-designated financial systems.

• Tracks and monitors progress of ITGC POA&Ms and remediation efforts at the Component level.

• Ensures completion of Memorandums of Understanding (MOUs) and Interconnection Security Agreements (ISAs) for CFO-designated financial system interconnections with any system not owned by DHS; ensures that they include appropriate security clauses;

and monitors service provider for compliance with MOUs and ISAs.

• Implements the Department-wide system development lifecycle methodology and monitor user compliance with this methodology.

• As part of developing new financial applications or updating existing applications, integrates CFO feedback to ensure user requirement are adequately addressed.

• Develops and tests Component-wide disaster recovery plan. Coordinate with Component CFO to incorporate business continuity requirements and test on a periodic basis.

• Based on Component CFO requirements, executes policies for the routine backing up and recovery of financial data. Implements policies and procedures for rotating back-up media off-site.

v5.5, September 30, 2007…