Attch_11__PBSOW_Appendix_I_-_DHS_4300A_Sensitive_Systems_Policy.pdf

DHS Sensitive Systems Policy Directive 4300A

Version 12.01 February 12, 2016

This Policy implements DHS Management Directive 140-01

“Information Technology System Security,” July 31, 2007

Protecting the Information that Secures the Homeland

DHS SENSITIVE SYSTEMS POLICY DIRECTIVE 4300A

v12.01, February 12, 2016 ii

This page intentionally left blank v12.01, February 12, 2016 iii

FOREWORD

The Department of Homeland Security (DHS) 4300 series of information security publications are the official documents that articulate Departmental policies, standards, and guidelines in accordance with DHS Management Directive 140-01 Information Technology System Security.

Comments concerning DHS Information Security publications are welcomed and should be submitted to the DHS Director of IT Security Policy and Remediation at infosecpolicy@hq.dhs.gov or addressed to:

DHS Director of IT Security Policy and Remediation OCIO CISO Stop 0182 Department of Homeland Security 245 Murray Lane SW Washington, DC 20528-0182

Jeffrey Eisensmith Chief Information Security Officer Department of Homeland Security mailto:INFOSEC@hq.dhs.gov v12.01, February 12, 2016 iv

This page intentionally left blank v12.01, February 12, 2016 v

TABLE OF CONTENTS

1.0 INTRODUCTION

1.1 Information Security Program

1.2 Authorities

1.3 Policy Overview

1.4 Definitions

1.4.1 Classified National Security Information

1.4.2 Component

1.4.3 Continuity of Operations

1.4.4 Continuity of Operations Plan (COOP)

1.4.5 DHS System

1.4.6 Essential Functions

1.4.7 Federal Information Security Modernization Act (FISMA)

1.4.8 Foreign Intelligence Information

1.4.9 General Support System

1.4.10 Information Technology

1.4.11 Major Application

1.4.12 National Intelligence Information

1.4.13 Operational Data

1.4.14 Personally Identifiable Information

1.4.15 Privacy Sensitive System

1.4.16 Privileged User

1.4.17 Public Information

1.4.18 Sensitive Information

1.4.19 Sensitive Personally Identifiable Information (SPII)

1.4.20 Sensitive System

1.4.21 Strong Authentication

1.4.22 Trust Zone

1.4.23 Two-Factor Authentication

1.4.24 Visitor

1.4.25 Vital Records

1.5 Waivers

1.5.1 Waiver Requests

1.5.2 Requests for Exception to U.S. Citizenship Requirement

1.6 Digital and Other Electronic Signatures

1.6.1 Digital Signatures and Other Electronic Signature Methods

1.6.2 Digital Signatures

1.7 Information Sharing

1.8 Threats

1.8.1 Insider Threats

1.8.2 Criminal Threats

1.8.3 Foreign Threats

1.8.4 Lost or Stolen Equipment

1.8.5 Supply Chain Threats

1.9 Changes to Policy

v12.01, February 12, 2016 vi

2.0 ROLES AND RESPONSIBILITIES

2.1 Information Security Program Roles

2.1.1 DHS Senior Agency Information Security Officer

2.1.2 DHS Chief Information Security Officer

2.1.3 Component Chief Information Security Officer

2.1.4 Component Information Systems Security Manager

2.1.5 Risk Executive

2.1.6 Authorizing Official

2.1.7 Security Control Assessor

2.1.8 Information Systems Security Officer

2.1.9 Ongoing Authorization Manager and Operational Risk Management

Board

2.1.10 DHS Security Operations Center

2.1.11 DHS Component Security Operations Centers

2.2 Other Roles

2.2.1 Secretary of Homeland Security

2.2.2 Under Secretaries and Heads of DHS Components

2.2.3 DHS Chief Information Officer

2.2.4 Component Chief Information Officer

2.2.5 DHS Chief Security Officer

2.2.6 DHS Chief Privacy Officer

2.2.7 DHS Chief Financial Officer

2.2.8 Program Managers

2.2.9 System Owners

2.2.10 Common Control Provider

2.2.11 DHS Employees, Contractors, and Others Working on Behalf of DHS ...47

3.0 MANAGEMENT POLICIES

3.1 Basic Requirements

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

3.5.2 Contingency Planning

3.6 Systems Engineering Life Cycle

3.7 Configuration Management

3.8 Risk Management

3.9 Security Authorization and Security Control Assessments

3.9.1 Ongoing Authorization

3.10 Information Security Review and Assistance

3.11 Security Working Groups and Forums

3.11.1 CISO Council

3.11.2 DHS Information Security Training Working Group

3.11.3 DHS Security Policy Working Group

3.11.4 DHS Enterprise Services Security Working Group

v12.01, February 12, 2016 vii

3.12 Information Security Policy Violation and Disciplinary Action

3.13 Required Reporting

3.14 Privacy and Data Security

3.14.1 Personally Identifiable Information

3.14.2 Privacy Threshold Analyses

3.14.3 Privacy Impact Assessments

3.14.4 System of Records Notices

3.14.5 Protecting Privacy Sensitive Systems

3.14.6 Privacy Incident Reporting

3.14.7 E-Authentication

3.14.8 Use Limitation and External Information Sharing

3.15 DHS CFO Designated Systems

3.16 Social Media

3.17 Health Insurance Portability and Accountability Act

3.18 Cloud Services

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 Segregation of Duties and Least Privilege

4.1.5 Information Security and Privacy Awareness, Training, and Education ...87

4.1.6 Separation from Duty

4.2 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 and Transport

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

4.5.3 Video Teleconferencing

4.5.4 Voice over Data Networks

4.6 Wireless Network Communications

4.6.1 Wireless Systems

4.6.2 Wireless Mobile Devices

4.6.2.1 Cellular Phones

4.6.2.2 Pagers

v12.01, February 12, 2016 viii

4.6.2.3 Multifunctional Wireless Devices

4.6.2.4 Bluetooth

4.6.3 Wireless Tactical Systems

4.6.4 Radio Frequency Identification

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

4.8.4 Hardware and Software

4.8.5 Personal Use of Government Office Equipment and DHS

Systems/Computers

4.8.6 Wireless Settings for Peripheral Equipment

4.9 Department Information Security Operations

4.9.1 Security Incidents and Incident Response and Reporting

4.9.2 Law Enforcement Incident Response

4.10 Documentation

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 and Policy Enforcement Points

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

5.5.3 Public Key/Private Key

5.6 Malware Protection

5.7 Product Assurance

5.8 Supply Chain

5.8.1 Business Impact

v12.01, February 12, 2016 ix

5.8.2 Supply Chain Risk Management Plans

6.0 DOCUMENT CHANGE REQUESTS

7.0 QUESTIONS AND COMMENTS

APPENDIX A ACRONYMS AND ABBREVIATIONS

APPENDIX B GLOSSARY

APPENDIX C REFERENCES

APPENDIX D DOCUMENT CHANGE HISTORY

v12.01, February 12, 2016 1

1.0 INTRODUCTION

This document articulates the Department of Homeland Security (DHS) Information Security Program policies for sensitive systems. Procedures for implementing these policies are outlined in a companion publication, DHS 4300A Sensitive Systems Handbook. This Policy Directive and the Handbook serve as the foundation on which Components are to develop and implement their own information security programs. The Baseline Security Requirements (BLSR) included in the Handbook must be addressed when developing and maintaining information security documents.

1.1 Information Security Program

The DHS Information Security Program provides a baseline of policies, procedures, standards, and guidelines for DHS Components. This Policy Directive provides direction to managers and senior executives for managing and protecting sensitive systems. It also defines policies relating to management, operational, and technical controls necessary for ensuring confidentiality, integrity, availability, authenticity, and nonrepudiation in DHS information system infrastructure and operations. The policy elements expressed in this Policy Directive are designed to be broad in scope to accommodate the diverse DHS operating environments. Each Component or Office is responsible for identifying, developing, and implementing any additional policies needed to meet their specific requirements. Implementation information can often be found in specific National Institute of Standards and Technology (NIST) publications, such as NIST Special Publication (SP) 800-53, Rev 4, “Security and Privacy Controls for Federal Information Systems and Organizations.”

This Policy Directive pertains to DHS Sensitive Systems, as distinct from DHS National Security Systems (NSS), which are governed by DHS National Security Systems Policy Directive 4300B series, available on the DHS Chief Information Security Officer (CISO) Web site. The 4300B series applies to all DHS elements, employees, contractors, detailees, others working on behalf of DHS, and users of DHS NSS that collect, generate, process, store, display, transmit, or receive Confidential, Secret, or Top Secret classified national security information.

Policy elements are effective when issued. Failure to implement any policy element within 135 days shall be considered a weakness, and either a system or program Plan of Action and Milestones (POA&M) must be generated by the Component for the identified weaknesses.

When this Policy Directive is changed, the DHS Chief Information Security Officer (CISO) will ensure that appropriate tool changes are made available to the Department within 90 days of the changes.

http://dhsconnect.dhs.gov/org/comp/mgmt/cio/iso/Pages/nss.aspx v12.01, February 12, 2016 2

1.2 Authorities

The following are authoritative references for the DHS Sensitive Information Security Program.

Additional references are located in Appendix C to this Policy Directive.

• E-Government Act of 2002, Public Law 107–347, 116 Stat. 2899, 44 U.S.C. 101

• Federal Information SecurityModernization Act of 2014 (FISMA), Public Law 113- 283; 128 Stat 3073

• Office of Management and Budget (OMB) Circular A-130, “Management of Federal Information Resources,” Transmittal Memorandum 4, 2010

• DHS Management Directive MD 140-01, “Information Technology Systems Security,” July 31, 2007

• National Institute of Standards and Technology (NIST) Federal Information Processing Standard FIPS 200, “Minimum Security Requirements for Federal Information and Information Systems,” March 2006

• NIST Special Publication (SP) 800-53, Rev 4, “Security and Privacy Controls for Federal Information Systems and Organizations,” April 2013, with updates as of January 22, 2015

• NIST SP 800-37, Rev 1, “Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach,” February 2010

1.3 Policy Overview

DHS information security policies define the security management structure and foundation needed to ensure adequate control over DHS sensitive information and systems. Policies in this document are organized in three sections:

• Management Controls – These controls focus on managing both system information security controls and system risk. These controls consist of risk mitigation techniques normally used by management.

• Operational Controls – These controls focus on mechanisms primarily implemented and executed by the people responsible for use of the system. Operational controls are designed to improve the security of a particular system or group of systems and often rely on management and technical controls.

• Technical Controls – These are the security controls executed by the information systems. Technical controls provide automated protection from unauthorized access or misuse; facilitate detection of security violations; and support security requirements for applications and data.

http://www.gpo.gov/fdsys/pkg/PLAW-113publ283/pdf/PLAW-113publ283.pdf http://www.gpo.gov/fdsys/pkg/PLAW-113publ283/pdf/PLAW-113publ283.pdf http://www.whitehouse.gov/omb/circulars_a130_a130trans4/ http://dhsconnect.dhs.gov/policies/Instructions/Directive%20140-01%20Information%20Technology%20Systems%20Security%20(Revision%2000).pdf http://dhsconnect.dhs.gov/policies/Instructions/Directive%20140-01%20Information%20Technology%20Systems%20Security%20(Revision%2000).pdf http://dhsconnect.dhs.gov/policies/Instructions/Directive%20140-01%20Information%20Technology%20Systems%20Security%20(Revision%2000).pdf http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf http://dx.doi.org/10.6028/NIST.SP.800-37r1 v12.01, February 12, 2016 3

DHS privacy controls have been added to DHS information security policy documents to comply with the publication of NIST SP 800-53, Rev.4, Appendix J: “Privacy Control Catalog.” The privacy controls focus on ensuring information privacy, distinct from, but closely related to information security. Privacy controls are the administrative, technical, and physical safeguards employed within organizations to protect and ensure the proper handling of Personally Identifiable Information (PII).

1.4 Definitions

The definitions in this section apply to the policies and procedures discussed in this document.

In general, the sources for the definitions given in this Section are relevant NIST documents.

Other definitions may be found in Committee on National Security Systems (CNSS) Instruction No. 4009, “National Information Assurance Glossary,” 26 April 2010. Definitions bearing on Privacy are sourced from Privacy Incident Handling Guidance and the Privacy Compliance documentation issued by the DHS Privacy Office.

1.4.1 Classified National Security Information

Information that has been determined, pursuant to Executive Order 13526, “Classified National Security Information,” to require protection against unauthorized disclosure and is marked to indicate its classified status. [Source: Executive Order 13526]

1.4.2 Component

A DHS Component is any organization which reports directly to the Office of the Secretary (including the Secretary, the Deputy Secretary, the Chief of Staff’s, Counselors, and staff, when approved as such by the Secretary), including both Operational Components and Support Components (also known as Headquarters Components). [Source DHS Lexicon and DHS Management Directive 112-01]

1.4.3 Continuity of Operations

Internal organizational efforts to ensure that a viable capability exists to continue essential functions across a wide range of potential emergencies, through plans and procedures that:

• Delineate essential functions and supporting information systems

• Specify succession of office and the emergency delegation of authority

• Provide for the safekeeping of vital records and databases

• Identify alternate operating facilities, if necessary

• Provide for interoperable communications

• Validate the capability to recover through tests, training, and exercises

1.4.4 Continuity of Operations Plan (COOP)

A predetermined set of instructions or procedures that describe how an organization’s mission-essential functions will be sustained within 12 hours and for up to 30 days as a result of a disaster event before returning to normal operations. [Source NIST SP 800-34] http://www.dhs.gov/xlibrary/assets/privacy/privacy_guide_pihg.pdf http://www.dhs.gov/Privacy v12.01, February 12, 2016 4

1.4.5 DHS System

A DHS system is any information system that transmits, stores, or processes data or information and 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 Essential Functions

Essential functions are those that enable Executive Branch agencies to provide vital services, exercise civil authority, maintain the safety and well being of the general populace, and sustain industrial capability and the national economy base during an emergency.

1.4.7 Federal Information Security Modernization Act (FISMA)

FISMA requires each agency to develop, document, and implement an agency-wide information security program that will provide a high level of security for the information and information systems supporting the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

FISMA requires that the Chief Information Officer (CIO) designate a senior agency information security official who shall develop and maintain a Department-wide information security program. The designee’s responsibilities include:

• Developing and maintaining information security policies, procedures, and control techniques that address all applicable requirements

• Training and overseeing personnel with significant information security responsibilities

• Assisting senior Department officials with respect to their responsibilities under the statute

• Ensuring that the Department has sufficient trained personnel to ensure the Department’s compliance with the statute and related policies, procedures, standards, and guidelines

• Ensuring that the Department CIO, in coordination with other senior Department officials, reports annually to the Secretary on the effectiveness of the Department’s information security program, including the progress of remedial actions

1.4.8 Foreign Intelligence Information

This type of information relates to the capabilities, intentions, and activities of foreign powers, organizations, or persons, but does not include counterintelligence (CI) except for information on international terrorist activities.

1.4.9 General Support System

A general support system (GSS) is an interconnected set of information resources that share common functionality and are under the same direct management control. A GSS normally includes hardware, software, information, applications, communications, data and users.

Examples of GSSs include local area networks (LAN), including smart terminals that support a v12.01, February 12, 2016 5 branch office, Department-wide backbones, communications networks, and Departmental data processing centers including their operating systems and utilities.

Security for GSSs in use at DHS Headquarters shall be under the oversight of the DHS Office of the Chief Information Officer (OCIO), with support from the DHS Security Operations Center (SOC). All other GSSs shall be under the direct oversight of respective Component CISOs, with support from the Component’s SOC. Every GSS must have an Information Systems Security Officer (ISSO) assigned.

1.4.10 Information Technology

Division E of the Clinger-Cohen Actof 1996 (Public Law 104-106) defines Information Technology (IT) 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”

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

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

The term information system as used in this policy document, is equivalent to the term information technology system.

1.4.11 Major Application

A major application (MA) is an automated information system (AIS) that OMB Circular A-130 defines as requiring “…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.”

All Federal applications require some level of protection. Certain applications, because of the information they contain, however, require special management oversight and should be classified as MAs. An MA is distinguishable from a GSS by the fact that it is a discrete application, whereas a GSS may support multiple applications. Each MA must be under the direct oversight of a Component CISO or Information System Security Manager (ISSM), and must have an ISSO assigned.

1.4.12 National Intelligence Information

The Intelligence Reform and Terrorism Prevention Act of 2004 (Public Law 108-458, 118 Stat.

3662) amended the National Security Act of 1947 (50 U.S.C. 401a) to provide the following definition:

‘‘(5) The terms ‘national intelligence’ and ‘intelligence related to national security’ refer to all intelligence, regardless of the source from which derived and including information gathered within or outside the United States, that—

(A) pertains, as determined consistent with any guidance issued by the President, to more than one United States Government agency; and v12.01, February 12, 2016 6

(B) that involves—

(i) threats to the United States, its people, property, or interests;

(ii) the development, proliferation, or use of weapons of mass destruction; or

(iii) any other matter bearing on United States national or homeland security.’’.

1.4.13 Operational Data

Operational data is information used in any DHS mission activity.

1.4.14 Personally Identifiable Information

Personally Identifiable Information (PII)” means information that permits the identity of an individual to be directly or indirectly inferred, including other information that is linked or linkable to an individual regardless of whether the individual is a United States citizen, legal permanent resident, or a visitor to the United States. [see also Sensitive Personally Identifiable Information (SPII)]

1.4.15 Privacy Sensitive System

A Privacy Sensitive System is any system that collects, uses, disseminates, or maintains PII or Sensitive PII.

1.4.16 Privileged User

A privileged user is a user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform. (Source: NISTIR 7298 rev 2.0

1.4.17 Public Information

Public information can be disclosed to the public without restriction, but requires protection against erroneous manipulation or alteration (e.g., public websites).

1.4.18 Sensitive Information

Sensitive Information is any information, which if lost, misused, disclosed, or, without authorization is accessed, or modified, could adversely affect the national or homeland security interest, the conduct of Federal programs, or the privacy of individuals, but which has not been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept secret in the interest of national defense, homeland security or foreign policy.

Sensitive Information includes:

• Chemical-terrorism Vulnerability Information (CVI)

• Protected Critical Infrastructure Information (PCII)

• Sensitive Security Information (SSI)

• Personally Identifiable Information (PII)

1.4.19 Sensitive Personally Identifiable Information (SPII)

Sensitive Personally Identifiable Information (SPII) is a subset of PII [see definition above], which if lost, compromised or disclosed without authorization, could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. Some forms of PII are sensitive as stand-alone elements..

v12.01, February 12, 2016 7

1.4.20 Sensitive System

A sensitive system is any combination of facilities, equipment, personnel, procedures, and communications that is integrated for a specific purpose, and that may be vulnerable to an adversarial attack by an adversary seeking to violate or disrupt the system’s confidentiality, integrity, or availability.

1.4.21 Strong Authentication

Strong authentication is a method used to secure computer systems and/or networks by verifying a user’s identity by requiring two-factors in order to authenticate (something you know, something you are, or something you have). Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. [See the discussion of Level 4 assurance in NIST SP 800- 63-2, “Electronic Authentication Guideline,” (August 2013)]

1.4.22 Trust Zone

A Trust Zone consists of any combination of people, information resources, IT systems, and networks that are subject to a shared security policy (a set of rules governing access to data and services). For example, a Trust Zone may be set up between different network segments that require specific usage policies based on information processed, such as law enforcement information.

1.4.23 Two-Factor Authentication

The classic paradigm for authentication systems identifies three factors as the cornerstone of authentication:

• Something you know (for example, a password or Personal Identification Number

(PIN)

• Something you have (for example, an ID badge or a cryptographic key)

• Something you are (for example, a fingerprint or other biometric data)

The strength of authentication systems is largely determined by the number of factors incorporated by the system. Implementations that use two factors are considered to be stronger than those that use only one factor.” A requirement for two of the three factors listed above constitutes two factor authentication.

1.4.24 Visitor

A guest or temporary employee who presents themselves or is presented by a sponsor, for entry for less than 6 months to a secured facility that is not their primary work location. (Source:

DHS Lexicon)

The visitor is placed in one of two categorizes, either escort required or no escort required.

Escort required visitors are escorted at all times. No escort required visitors are granted limited general access to the facility without an escort. Escort procedures for classified areas are indicated in Management Directive 11051 “SCIF Escort Procedures.” (Source: DHS Lexicon) http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf v12.01, February 12, 2016 8

1.4.25 Vital Records

Vital records are electronic and hardcopy documents, references, databases, and information systems needed to support essential functions under the full spectrum of emergencies.

Categories of vital records may include:

• Emergency operating records: emergency plans and directive(s); orders of succession; delegations of authority; staffing assignments; selected program records needed to continue the most critical agency operations; and related policy or procedural records.

• Legal and financial rights records: records that protect the legal and financial rights of the Government and of the individuals directly affected by its activities. Examples include accounts receivable records, social security records, payroll records, retirement records, and insurance records. These records were formerly defined as “rights-and-interests” records.

• Records used to perform national security preparedness functions and activities in accordance with Executive Order (EO).

1.5 Waivers

When a Component is unable to fully comply with any portion of this Policy Directive, it may request a waiver. Waiver requests should be routed through the Component’s ISSO for the system, to the Component’s CISO or ISSM, and then to the DHS CISO. All submitters shall coordinate with the Authorizing Official (AO) prior to submission.

If a material weakness is reported in an audit report, and the weakness is not scheduled for remediation within 12 months, the Component must submit a waiver request to the DHS CISO.

If the material weakness exists in a financial system, the Component Chief Financial Officer (CFO) must also approve the waiver request before sending to the DHS CISO. If the material weakness exists in a system processing PII, the Component Privacy Officer or Privacy Point of Contact (PPOC) and DHS Chief Privacy Officer must also approve the waiver request before sending to the DHS CISO.

An approved waiver does not bring the system into compliance with policy; it is an acknowledgement by the DHS CISO of the system’s non-compliance with policy and that an acceptable plan to remediate the weakness has been provided and compensating controls have been implemented.

In all cases, waivers shall be requested for an appropriate period based on a reasonable remediation strategy.

1.5.1 Waiver Requests

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

Component ISSOs, audit liaisons, and others may develop the waiver request, but the System Owner shall submit the request through the Component’s CISO/ISSM. All submitters shall coordinate with the Authorizing Official (AO) prior to submission v12.01, February 12, 2016 9

Waiver requests shall include documentation of mission impact as operational justification;

mission impact; risk acceptance; risk mitigation measures; and a current POA&M for bringing the system control weakness into compliance.

Additionally, any waiver requests for financial systems must be submitted to and approved by the Component’s CFO prior to submission to the DHS CISO. Any waiver request for sensitive systems with PII information must be submitted to and approved by the Component’s Privacy Officer or senior PPOC prior to being submitted to the DHS CISO.

Any waiver for compliance with privacy controls must be submitted to and approved by the DHS Chief Privacy Officer.

Policy ID DHS Policy Statements Relevant

Controls

1.5.1.a This Policy Directive and the DHS 4300A Sensitive Systems Handbook apply to all DHS employees, contractors, detailees, others working on behalf of DHS, and users of DHS information systems that collect, generate, process, store, display, transmit, or receive DHS information unless an approved waiver has been granted. This includes prototypes, telecommunications systems, and all systems in all phases of the Systems Engineering Life Cycle

(SELC).

SA-3

1.5.1.b Systems not yet authorized to operate when this policy is issued shall comply with all of its policy statements or obtain appropriate waivers. Systems with an Authority to Operate (ATO) shall comply within 135 days of the date of this Policy is issued or obtain appropriate waivers. (A new ATO is only required for significant changes.)

PL-1

1.5.1.c Components shall request a waiver whenever they are unable to comply fully with any portion of this policy.

CA-2

1.5.1.d The Component CISO/ISSM shall approve all waiver requests prior to submitting them to the DHS CISO.

CA-6

1.5.1.e The Component CIO shall approve any waiver request that results in a total waiver time exceeding (12 months before sending the request to the DHS

CISO.

1.5.1.f The Component CFO shall approve all requests for waivers for financial systems prior to their submission to the DHS CISO.

CA-6

1.5.1.g The Component’s Privacy Officer or Senior PPOC shall approve all requests for waivers for sensitive systems processing PII or SPII prior to their submission to the DHS CISO.

v12.01, February 12, 2016 10

Controls

1.5.1.h The DHS Chief Privacy Officer shall approve all requests for waivers for compliance with any privacy control in Appendix J of NIST SP 800-53 prior to their submission to the DHS CISO.

1.5.2 Requests for Exception to U.S. Citizenship Requirement

Special procedures apply for exception to the requirement that persons accessing DHS systems be U.S. citizens. Under normal circumstances, only U.S. citizens are allowed access to DHS systems and networks; but there is a need at times to grant access to foreign nationals. Access for foreign nationals is normally a long-term commitment, and exceptions to citizenship requirements are treated differently from security policy waivers. Exceptions to the U.S.

citizenship requirement should be requested by completing a Foreign National Visitor Access Request, DHS Form 11052-1, which is available online or through the DHS Office of the Chief Security Officer (OCSO). Components who have access may file their request via the Foreign National Vetting Management System (FNVMS), a part of the DHS OCSO Integrated Security Management System’s (ISMS). For further information regarding the citizenship exception process, contact the DHS OCSO at foreign.visitors@hq.dhs.gov.

Controls

1.5.2.a Any Person of dual-citizenship (one being a US citizenship) and any Legal Permanent Resident who requires access to DHS systems as a validated representative of foreign power shall be processed as indicated in Section 1.5.2.

1.5.2.b Exceptions to the U.S. Citizenship requirement shall be requested by submitting a completed Foreign National Visitor Access Request form to the DHS Office of the OCSO for each foreign national requiring access to DHS systems and networks.

PS-3

1.5.2.c Component CISOs shall select a Foreign Access Coordinator to be the point of contact to the DHS OCSO for processing requests for exception to the U.S.

Citizenship policy requirement (4.1.1.e). The Component shall notify OCSO of the selected Foreign Access Coordinator.

1.5.2.d Foreign Access Coordinators shall, in coordination with the DHS OCSO, conduct an assessment of the risk of granting access to DHS systems by the Foreign National specified and provide a recommendation to the Component CISO regarding the approval or disapproval of the request.

mailto:foreign.visitors@hq.dhs.gov v12.01, February 12, 2016 11

1.6 Digital and Other Electronic Signatures

Pursuant to Sections 1703 and 1705 of the Government Paperwork Elimination Act (GPEA), OMB Memorandum M-00-10, “Procedures and Guidance on Implementing of the Government Paperwork Elimination Act” requires executive agencies to provide the option for electronic maintenance, submission, and disclosure of information when practicable as a substitute for paper, and to use and accept electronic signatures.

Electronic signatures are essential in the Department’s business processes and IT environments;

reducing reliance on paper transactions improves information sharing, strengthens information security, and streamlines business processes, while reducing both cost and environmental impact.

Please refer to the “DHS Electronic Signature Policy Guidance” document for guidance on electronic signature policy

1.6.1 Digital Signatures and Other Electronic Signature Methods

The following DHS Policy Statements are applicable to both digital signatures and other electronic signature methods.

Controls

1.6.1.a Digital signatures or other electronic signature methods shall be used whenever practical, except where handwritten signatures are required by law, regulation, Executive Order, or other agency requirement. Digital signature or other electronic signature methods, when properly executed, shall be accepted to the maximum extent practicable.

1.6.1.b Electronic signatures, including digital signatures, shall be implemented by applications with the necessary security controls and practices such that:

1) the signer cannot successfully repudiate that he/she intended to sign, or that he/she applied the electronic signature; and

2) the integrity of the signed content cannot be successfully challenged.

http://mgmt-ocio-sp.dhs.gov/pki/Enterprise%20Electronic%20and%20Digital%20Signature/Forms/AllItems.aspx?RootFolder=%2Fpki%2FEnterprise%20Electronic%20and%20Digital%20Signature%2FDeliverables&FolderCTID=0x0120002826DECA39BC494B8C7C8FA26319DE4F&View=%7bB1BE2D4F-1571-4645-B93E-2CF8A32F8591%7d&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence v12.01, February 12, 2016 12

Controls

1.6.1.c When a signature is required on electronic documents, transactions, communications, etc. for use within DHS, or for use for intra-governmental transactions, communications, etc., where all potential signers possess a Personal Identity Verification (PIV) card, Department of Defense (DOD)-issued Common Access Card (CAC), or PIV-I card (and the associated card readers, software, and verification processes are in place), the signing process shall employ a digital signature created by a properly identified signer through the use of their PIV card, CAC issued by DOD, or PIV-I card, whenever possible.

Signers may use their software-based digital signature certificate that meets the requirements specified in Section 1.6.2.a below for signing when their PIV card, DOD-issued CAC, or PIV-I card cannot be used.

Other electronic signature methods may be used when it is determined that it is not possible for the signer to use his/her PIV card, DOD-issued CAC, PIV-I card, or software-based digital signature certificate that meets the requirements specified in Section 1.6.2.a below. For legally binding signatures, the determination of what other electronic signature method shall be used must be based on a risk assessment of the likelihood of a successful challenge to the enforceability of the signature, and the monetary loss, or other adverse impact of an unenforceable signature.

1.6.1.d The following requirements shall be met when implementing legally binding signatures using Digital Signature or an Other Electronic Signature Method:

1) The Signer must use an acceptable electronic form of signature;

2) The electronic form of signature must be executed or adopted by a person with the intent to sign the electronic record;

3) The electronic form of signature must be attached to or associated with the electronic record being signed;

4) There must be a means to identify and authenticate a particular person as the signer; and

5) There must be a means to preserve the integrity of the signed record.

1.6.1.e When implementing one or more legally binding Digital Signatures in an electronic document, transaction, communication, etc., and the intent to sign for each signature is not evidenced by the context of the content being signed, a clear and conspicuous notice shall be incorporated into that electronic document, transaction, communication, etc., just prior to the location each signature, that indicates:

1) That an electronic signature is being created, and what constitutes the execution of the signature,

2) The reason for signing (for that specific signature), and

3) That when completed, it will constitute the Signer’s legally binding signature.

v12.01, February 12, 2016 13

Controls

1.6.1.f When implementing legally binding electronic signatures for a specific use, where Other Electronic Signature Methods will be used, the risk assessment process, described in the “DHS Electronic Signature Policy Guidance” document, Section I.G. “Determining Which Electronic Signature Method to Use - Risk Assessment and Cost-Benefit Analysis”, shall be used to determine the overall level of risk, and the specific approaches to be implemented to meet each of the following five requirements for legally binding signatures:

1) The Signer must use an acceptable electronic form of signature;

2) The electronic form of signature must be executed or adopted by a person with the intent to sign the electronic record;

3) The electronic form of signature must be attached to or associated with the electronic record being signed;

4) There must be a means to identify and authenticate a particular person as the signer;

5) There must be a means to preserve the integrity of the signed record.

1.6.1.g The date and time a legally binding signature is executed, using Digital Signature or an Other Electronic Signature Method, shall be captured and incorporated as part of the record of the signature. The captured date and time must be accurate and trustworthy.

Within DHS, legally binding signatures using a digital signature or other electronic signature method shall be executed on systems whose system clocks have been synchronized via Network Time Protocol (NTP) with DHS networks, and are managed to prevent unauthorized changes to the system clock. When the signature is executed, the date and time from the system clock shall be captured and incorporated as part of the record of the signature.

When a legally binding signature must be executed on a system whose system clock is not synchronized via NTP and not managed to prevent unauthorized changes to the system clock, the signer is responsible for ensuring that the date and time incorporated as part of the record of the signature is accurate.

1.6.1.h The visual context of an electronic signature implemented using digital signature or other electronic signature method, shall be maintained. The Relying Parties for the electronically signed document, transaction, communication, etc. must be able to view the exact format and content of the document, transaction, communication, etc. that the Signer saw when he or she signed it.

v12.01, February 12, 2016 14

Controls

1.6.1.i Where a DHS entity is the Relying Party for an electronic signature executed on a non-DHS system by an external signer, using a digital signature or other electronic signature method, the DHS entity shall determine whether the asserted signing date and time is sufficiently accurate and trustworthy to be acceptable for the intended use of the signature.

1.6.1.j Electronically signed records shall be maintained based on operational needs, perception of risks, and historical value, as formalized through corresponding Records Disposition Schedules approved by the National Archives and Records Administration (NARA). Operational needs shall be determined on the basis of the approach taken to ensure the availability, accessibility, and trustworthiness of electronically signed records over time.

1.6.1. k The Component CISO shall approve the design, development, resources and infrastructure for implementations of electronic signatures using Digital Signatures or Other Electronic Signature Methods. The adoption and integration of legally binding electronic signature capabilities into workflows, business processes, specific document types, etc., shall be reviewed and approved by the Component General Counsel and by the Component Chief Records Officer. Additional review/endorsement by other cognizant officials (e.g., Privacy Officer; Chief Financial Officer; Forms Management Officer;

etc.) shall be obtained when appropriate.

1.6.1.l All implementations of digital signatures or other electronic signature methods in DHS shall comply with the requirements of DHS Sensitive Systems Policy Directive 4300A.

Existing (legacy) implementations of electronic signatures shall be brought into compliance with DHS Sensitive Systems Policy Directive 4300A as soon as is practical, but in no case later than 12 months, or a waiver must be obtained.

The waiver shall be requested in writing and submitted to the DHS CISO.

1.6.2 Digital Signatures

The following policy statements are applicable only to digital signatures.

v12.01, February 12, 2016 15

Controls

1.6.2.a Digital signatures shall not be accepted unless the following conditions are met:

1) Standard Path Development and Validation (PDVAL) software verifies the validity of the signer’s signature verification certificate as of the time the signature was executed; and

2) The certificate is authorized for signature use ( i.e., has the digital signature and non-repudiation key usage bits set in the keyUsage extension); and

3) The certificate was;

i) Issued by DHS Principal Certification Authority (CA) (DHS CA4) under one of the following U.S. Common Policy Framework certificate policies, as indicated by the Policy Object Identifier (OID) entered in the Certificate Policies extension in the certificate; or

ii) Issued by another U.S. Federal Government (CA that is subordinate to the U.S. Common Root CA under one of the following U.S. Common Policy Framework certificate policies, as indicated by the Policy OID entered in the Certificate Policies extension in the certificate; or

iii) Issued by a CA from another PKI cross-certified with the Federal Bridge Certification Authority (FBCA), where the certificate is issued under a certificate policy that maps to one of the following FBCA certificate policies, Policy Policy Object Identifier id-fpki-common-policy ::= {2 16 840 1 101 3 2 1 3 6} id-fpki-common-hardware ::= {2 16 840 1 101 3 2 1 3 7} id-fpki-common-High ::= {2 16 840 1 101 3 2 1 3 16}

Policy Policy Object Identifier id-fpki-common-policy ::= {2 16 840 1 101 3 2 1 3 6} id-fpki-common-hardware ::= {2 16 840 1 101 3 2 1 3 7} id-fpki-common-High ::= {2 16 840 1 101 3 2 1 3 16} v12.01, February 12, 2016 16

Controls as indicated by the PolicyMappings extension in the cross-certificate issued by the FBCA to the Root CA for the Signer’s PKI, mapping an appropriate FBCA policy OID from the table above to the policy OID in the Certificate Policies extension from the Signer’s certificate.

Policy Policy Object Identifier id-fpki-certpcy-mediumAssurance

::= { 2 16 840 1 101 3 2 1 3 3 } id-fpki-certpcy-mediumHardware

::= { 2 16 840 1 101 3 2 1 3 12 } id-fpki-certpcy-highAssurance

::= { 2 16 840 1 101 3 2 1 3 4 } id-fpki-certpcy-pivi-hardware

::= { 2 16 840 1 101 3 2 1 3 18 }

1.6.2.b If a digital signature is time stamped by a Trusted Timestamp Authority approved by the DHS CISO, DHS relying parties for the signature shall accept the time stamp as a trustworthy indicator that the digital signature was executed prior to that time.

1.6.2.c For electronic documents, transactions, communications, etc. containing legally binding digital signatures, a visible signature block containing information about the signer and the signature shall be embedded for each signature, when possible. The visible signature block for each signature shall be located in proximity to, but after the statement in the document, transaction, communications, etc. indicating the intent of that signature.

The visible signature block shall be formatted to clearly indicate that it is a block of information about the signature, and shall contain:

1) The name of the signer (mandatory)

2) The Role of the signer (mandatory)

3) The date and time the signature was executed (mandatory)

4) A graphical depiction or image of the signer’s handwritten signature (recommended)

5) Additional information as appropriate (optional)

The presence of a visual signature block shall not be used to indicate that a digital signature has been validated. A relying party must validate a digital signature using standard Path Development and Validation (PDVAL) protocols each time they make a determination to trust on not trust the digital signature.

1.6.2.d Since any change to a digitally signed record will prevent validation of the digital signature, the use of stable file formats, with broad product support for v12.01, February 12, 2016 17

Controls backwards compatibility is essential to maintaining digitally signed records.

Electronic documents, transactions, communications, etc. to be digitally signed shall be limited to file formats that will be stable over the retention period of the signed record.

Suggested stable standard file formats include, but are not limited to:

1) American Standard Code for Information Exchange (ASCII)(.txt)

2) Portable Document Format (.pdf), ISO 3200

3) Open Office Extended Markup Language (XML) File Formats, ECMA-376, ISO/IEC 29500

i) XML Document Format (.docx)

ii) XML Workbook Format (.xlxs)

iii) XML Presentation Format (.pptx)

1.6.2.e Using a combination of digital signatures and handwritten signatures on a single document, transaction, message, etc. shall be avoided whenever possible, to ensure that a single record can be created where all of the signatures are part of the record and can be validated by Relying Parties.

1.6.2.f In order to facilitate interoperability, DHS implementations of digital signatures shall comply with the PDF Advanced Electronic Signature (PAdES) standard or XML Advanced Electronic Signature (XAdES) standard for digital signature formats.

1.6.2.g For DHS electronic records that are digitally signed, the digital signatures shall be verifiable by relying parties for the entire retention period of the record.

The digital signatures shall be verifiable using standard PDVAL protocols (http://www.idmanagement.gov/path-discovery-and-validation).

1.6.2.h When a digital signature is applied to an email by a DHS entity, it shall be for security purposes only, i.e., to enable the recipient or a third party to determine the source of the email and its integrity.

Email may be used as a transport mechanism to send documents, transactions, messages, etc., that include legally binding digital signatures, as attachments to an email.

If an email is received containing a digital signature that is intended to be legally binding, the source of the email shall be contacted and asked to re-submit the relevant content signed with the legally binding signature as an email attachment, or via another acceptable means.

1.6.2.i A public-private key pair is only valid for the uses specified in the public key’s certificate. Only private keys with an associated public key certificate that asserts both the digital signature and non-repudiation bits in the keyUsage v12.01, February 12, 2016 18

Controls extension shall be used to execute legally binding digital signatures. Digital signatures executed with a private key with associated public key certificate that does not assert both the digital signature and non-repudiation bits in the keyUsage extension shall be rejected (not accepted).

Key pairs with associated public key certificates intended for authentication or encryption use shall not be used to execute digital signatures, and digital signatures generated with them shall not be accepted.