Amendment 0003 SOW Attachment 8a -DHS 4300A ITSSP SS Policy Directive.pdf

U.S. Department of Homeland Security

DHS Policy Directive

Number: 4300A

Version 13.2 Issue Date: September 20, 2022

Information Technology System Security Program, Sensitive Systems

Kenneth Bible

09/20/2022_ Date

Chief Information Security Officer

DHS 4300A Information Technology System Security Program, Sensitive Systems ii 8/22/2022

Version 1.0

DOCUMENT CHANGE HISTORY

Issue Date Pages Affected Description

1.0.0 August 22, 2022 All This version rewritten around the

NIST SP 800-53, Revision 5 Control Families, all instructions, procedures and SOP non-appli-cable policy statements moved to the attachment documents, au-thorities updated, and comments adjudicated and implemented from the Policy Working Group and all participating component representatives (Barbara Brough, Risk Management and Compli-ance , Assessments Branch) iii

TABLE OF CONTENTS

1) Introduction………………………………………………………………………………………5

2) Information Security Program

3) Purpose

4) Rescission

5) Applicability

6) Effective Implementation Date

7) Policy

a) Access Control (AC)……………………………………………………………………….10

b) Awareness and Training (AT)…………………………………………………………….13

c) Audit and Accountability (AU)……………………………………………………………16

d) Assessment, Authorization, and Monitoring (CA)………………………………………18

e) Configuration Management (CM)…………………………………………………….…..25

f) Contingency Planning (CP)………………………………………………………………..26

g) Identification and Authentication (IA)…………………………………………………...28

h) Incident Response (IR)………………………………………………………………….…31

i) Maintenance (MA)………………………………………………………………………….33

j) Media Protection (MP)…………………………………………………………………

k) Personally Identifiable Information Processing and Transparency (PT)…….…..……35

l) Personnel Security (PS)…………………………………………………………………….39

m) Physical and Environment Protection (PE)…………………………………………

n) Planning (PL)……………………………………………………………………...……….44

o) Program Management (PM)………………………………………………………………50

p) Risk Assessment (RA)……………………………………………………………………...52

q) System and Services Acquisition (SA)…………………………………………………….53

r) System and Communication Protection (SC)…………………………………………….55

s) System and Information Integrity (SI)……………………………………………………57 iv

t) Supply Chain (SR)………………………………………………………………………….58

Definitions

Acronyms …………………………………………………………………………………………..82

Authorities and References

DHS 4300A, “Information Technology System Security Program, Sensitive Systems”

1) Introduction

Organizations depend on information systems to carry out their missions and business func-tions. The success of the mission and business functions depends on protecting the confi-dentiality, integrity, and availability of information processed, stored, and transmitted by those systems. The threats to information systems include equipment failure, environmental disruptions, human or machine errors, and purposeful attacks that are often sophisticated, disciplined, well-organized, and well-funded. When successful, attacks on information sys-tems can result in serious or catastrophic damage to organizational operations and assets, individuals, other organizations, and the Nation. Therefore, it is imperative that organiza-tions remain vigilant, and that senior executives, leaders, and managers understand their re-sponsibilities and are accountable for protecting organizational assets and for managing risk.

The E-Government Act of 2002 (Public Law 107-347) recognized the importance of infor-mation security to the economic and national security interests of the United States. Title III of the E-Government Act, entitled the Federal Information Security Management Act (FISMA) of 2002, requires each federal agency to develop, document, and implement an agency-wide information security program to provide information security that supports the operations of the agency, including those provided or managed by another agency, contrac-tor, or other source. The Federal Information Security Modernization Act (FISMA) of 2014 amended the FISMA of 2002, providing several modifications that modernize federal secu-rity and privacy practices to address evolving security concerns. One of these changes is to emphasize risk-based policy standards for federal information and information systems for cost-effective security and privacy.

The Presidential Executive Order (EO) 13800, Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure (May 11, 2017) and (EO) 14028 Improv-ing the Nation’s Cybersecurity (May 21, 2021) also outlined actions to enhance cyber-security across federal agencies and critical infrastructure partners, and reinforces

FISMA 2014.

The Department of Homeland Security (DHS) Information Security Program lays the foun-dation for DHS security personnel to implement and maintain secure DHS information sys-tem design, operation, and maintenance. Information security policy makes certain as-sumptions about protection measures that respond to other DHS security policies and prac-tices (e.g., physical and personnel security). For example, this policy presupposes reliable processes for confirming the credentials of prospective system users. Information security policy also presumes the enforcement of suitable physical protection from the means of ac-cess to facilities storing DHS’s IT resources.

The requirements of this policy complement other agency measures for effective manage-ment of assets and regulatory compliance (e.g., with the federal privacy laws). References are made to those sources throughout this document (latest version published is refer-enced). As the primary information source for fundamental requirements for maintaining the confidentiality, integrity, and availability of information technology (IT) resources, the policy identifies and characterizes a comprehensive set of basic protection goals without stipulating how the goals should be met (i.e., the specific technologies, mechanisms, or procedures involved).

2) Information System Security Program The DHS Information System Security Program, Sensitive Systems, provides a baseline of policies, procedures, standards, and guidelines for DHS Components. This Policy Directive provides direction to managers and senior leadership on how to manage and protect sensitive systems. It also defines policies relating to managerial, 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 Directive are designed to be broad in scope to accommodate diverse operating environ-ments. Each DHS Component is responsible for the identification, development, and imple-mentation of any additional policies needed to meet their specific requirements. Implementa-tion information can often be found in specific National Institute of Standards and Technology (NIST) publications, such as NIST Special Publication (SP) 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations.

This Policy Directive pertains to DHS Sensitive Systems, as distinct from the DHS National Security Systems (NSS), which are governed by the DHS National Security Systems Policy Directive 4300B series1. The 4300B policy 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 Unclassified, Confidential, Secret, Top Secret (TS), or Special Access Program (SAP) National Security Information (NSI). Please see DHS Management Directive 140-01, “Information Technology System Security Program” for additional detail.

Policy elements are effective when issued. Failure to implement any policy element within 135 days of discovery is considered a weakness, and either a system or program Plan of Ac-tion and Milestones (POA&M) is generated by the Component for the identified weaknesses within 145 days from discovery and submitted to the FISMA repository. When this Policy Di-rective is changed, the DHS Chief Information Officer (CIO), via the Chief Information Secu-rity Officer (CISO), will ensure that appropriate tool changes are made available to the De-partment within 90 days of the policy change.

1 National Security Cyber Division (dhs.gov) https://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/Pages/nscd.aspx

3) Purpose This DHS Policy Directive 4300A, “Information Technology System Security Program, Sensitive Systems,” hereafter known as DHS 4300A, establishes the information security policy for DHS. This program is based on federal security regulations and highlights DHS’s goals and requirements for protecting its’ information and information system assets. This program prescribes responsibilities, practices, and conditions that directly or indirectly pro-mote security in the development, operation, maintenance, and support of all DHS IT re-sources. This program also identifies security practices that align with DHS’s mission, pro-vides cost-effective protection of DHS’s information and information systems, and responds to security and privacy issues associated with contemporary technologies and risks. This program is aligned with current and applicable federal security laws, policies, and regula-tions.

This program is intended to provide protection goals and standards by providing a comprehen-sive view of information security and privacy considerations to all DHS Components, personnel, and information systems. It addresses technical security services, as well as the management and operational requirements for information security. This program identifies all relevant security and privacy roles and responsibilities, as well as affected organizations. This program also re-flects the increasing requirements needed for internal and external security oversight from the DHS Office of Inspector General (OIG) and for responding to FISMA requirements.

The scope of this policy is as follows:

a) The policy statements in the DHS 4300A, in alignment with NIST SP 800-53, Revision 5, address security and privacy controls in the DHS Control Base-lines which apply to low, moderate, and high impact systems. See Attach-ment CC, the DHS Security and Privacy Control Baseline with Operationally Defined Values (ODV), hereafter known as the DHS Control Baseline, for ad-ditional details. DISA Security Technical Implementation Guides, or STIGs, are used as configuration checklists referring to the DHS Baseline and used as both a Configuration checklist and assessment guide as a part of the con-trol implementation and validation process.

b) The Cybersecurity Framework (CSF) Subcategoriesi (or controls) are not within the scope of this policy. However, the CSF Subcategories are mapped to the con-trols within each control family in the Security and Privacy Control Catalog to provide a better overview of the control family.

4) Rescission

This policy supersedes the DHS 4300A Sensitive Systems Policy and Sensitive

Systems Policy Handbook. See authorities for additional memos, directives, and policies included in this document.

5) Applicability

The DHS 4300A is intended to serve a diverse audience within DHS, including:

a) Individuals with system, information security, privacy, or risk manage-ment and oversight responsibilities.

b) Employees, contractors, and service providers with system development responsi-bilities including, for example, system owners, program managers, systems engi-neers, systems security engineers, privacy engineers, software developers, systems integrators, and acquisition or procurement officials.

c) Employees, contractors, and service providers with security and privacy im-plementation and operations responsibilities including, for example, Pro-gram Offices, mission or business owners, system owners, information own-ers or stewards, system administrators/engineers, network engineers, sys-tem security or privacy officers.

d) Employees, contractors, and service providers with security and privacy as-sessment and monitoring responsibilities including, for example, auditors, Inspectors General, system evaluators, control assessors, independent verifi-ers and validators, and analysts.

e) Users of DHS information systems, including employees, contractors, and members of the general public, especially users of these systems who are not information security professionals and have a limited understanding of the complexities of threats facing DHS systems. The DHS Information Se-curity Program must support users by providing systems that accomplish security objectives in a manner that provides for the continued utility and usability of these systems.

6) Effective Implementation Date The authority for the issuance of this policy rests with the CIO and is assigned to the DHS Chief Information Security Office Directorate (CISOD). DHS CISOD serves as the central focal point for cybersecurity within DHS. This DHS Information Security Program is ef-fective in accordance with the established timeline for transition and implementation ap-proved by the CISO Council.

This Policy Directive will be reviewed annually from the date of issuance to assess its ef-fectiveness and update as necessary, when implementation challenges arise, or when im-pacted by a significant change or underlying standard. For example, the potential use of newer technologies (e.g., wireless communications) may give rise to additional policy re-quirements. In such cases, the policy will outline the basic relevant security and privacy policy requirements; however, in general, the policy is free from low-level procedural and technical detail.

All updates to this Policy Directive shall be subject to the DHS-wide clearance process providing an opportunity for stakeholders to comment on the subject matter and content of the directive, such as on the implication of programmatic implementation of the proposed updates.

7) Policy

DHS information security and privacy policies are based on Federal Information Security Modernization Act of 2014 (FISMA 2014) and the Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource (July 28, 2016). This policy document integrates the security and privacy requirements from the Federal Infor-mation Processing Standards (FIPS) 200, Minimum Security Requirements for Federal Infor-mation and Information Systems, and controls that are documented in NIST SP 800-53, Revi-sion 5, Security and Privacy Controls for Information Systems and Organizations (December 2020), with DHS-specific requirements.

This Policy Directive is intended to simplify compliance with current versions of FIPS 200 and NIST SP 800-53, Revision 5, which is the basis of the DHS Control Baseline and Or-ganizational Defined Values (ODV). See Attachment CC of this Policy Directive DHS Baselines and ODVs for additional detail. This Policy Directive is organized by NIST se-curity and privacy control families. Each new control family has an overview and descrip-tion of the family followed by high-level policy statements.

Policy Overview

DHS information security policies define the security management structure and foundation needed to ensure adequate control over DHS sensitive information and systems.

Authorities

The following are authoritative references for the DHS Sensitive Information Security Pro-gram. Additional references are located in the Authorities and References section of this Di-rective.

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

• Federal Information Security Modernization Act of 2014 (FISMA), Public Law https://www.congress.gov/bill/113th-congress/senate-bill/2521 https://www.congress.gov/bill/113th-congress/senate-bill/2521 https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf https://www.justice.gov/opcl/e-government-act-2002 http://www.gpo.gov/fdsys/pkg/PLAW-113publ283/pdf/PLAW-113publ283.pdf

113- 283; 128 Stat 3073

• Cybersecurity Information Sharing Act of 2015.

• Office of Management and Budget (OMB) Circular A- 123 “Managing Infor-mation as a Strategic Resource,” July 2016.

• DHS Management Directive 140-01 “Information Technology System Security Pro-gram.”

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

• NIST SP 800-53, Revision 5, “Security and Privacy Controls for Infor-mation Systems and Organizations,” December 2020.

• NIST SP 800-37, Revision 2, “Risk Management Framework for Information Systems and Organizations,” December 2018.

(AC) Access Control Family

Access control is a method of guaranteeing that users are who they say they are and that they have the authorized access to the data being sought. At a high level, access control is a selec-tive restriction of access to data. Access control addresses user authorization to utilize an in-formation system. It also addresses the processes and types of transactions that are allowed.

Who should access DHS’s data? How does DHS ensure those who attempted access have unequivocally been granted that access? Under which circumstances do you deny access to a user with access privileges?

To effectively protect its data, DHS’s access control policy must address these questions.

Information system access must be limited to authorized users, processes acting on behalf of authorized users, or devices (including other information systems). This promotes the least functionality paradigm by giving people, processes, or devices the most basic functionality required for completing tasks as a basic user or a privileged account holder.

http://www.gpo.gov/fdsys/pkg/PLAW-113publ283/pdf/PLAW-113publ283.pdf http://www.gpo.gov/fdsys/pkg/PLAW-113publ283/pdf/PLAW-113publ283.pdf https://obamawhitehouse.archives.gov/omb/circulars_a123/ https://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ito/ITSO%20Policy/140-01%20Information%20Technology%20Systems%20Security%20(Revision%2000).pdf#search=DHS%20MD%20140%2D01 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 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf

DHS’s access control requirements, at a minimum, shall:

1. Employ at the component level, a centralized identity management system for user accounts, including:

a) Suspend accounts for personnel on extended absences, as defined by Human Re-sources

b) Employ a process to record and monitor significant changes to user accounts and groups to ensure access is not granted outside the formal DHS approval process

c) Create and assign administrator accounts separate from normal user accounts for individuals requiring escalated privileges.

d) Ensure system owners review information system accounts supporting their pro-grams at least annually and when major changes occur to the systems environ-ments.

e) Ensure separation of duties to prevent abuse of authorized privileges and help to reduce the risk of malevolent activity without collusion.

f) Employ least privilege for job roles on DHS information systems to ensure that the processes operate at privilege levels no higher than necessary to accomplish required DHS missions/business functions. Develop policy for the use of pass-word managers (e.g. LastPass, CyberArk, cloud based solutions such as Azure Active Directory, etc.,)

2. For DHS employees that leverage internal or external resources that use passwords for access control. See NIST SP 800-63 for additional password guidelines.

3. Enable the use of Multifactor Authentication as outlined in Homeland Security Presidential Directive (HSPD)-12 which mandates a federal standard for secure and reliable forms of identification [e.g., Personal Identity Verification (PIV) Card].

a) Components shall provide phishing-resistant authentication methods (e.g., FIDO2, Web Authentication) for its systems. See NIST 800-63b for additional details.

b) Components shall provide phishing-resistant authentication methods for public-facing systems that support multi-factor authentication.

4. Develop a policy on data exchange and interconnection security agreements (ISAs) for all DHS systems connected to external systems. Ensure prevention of unauthorized access to DHS information systems and networks. See FIPS 199 and NIST 800-171 for requirements.

5. Ensure DHS Components develop and document access agreements for information systems and ensure that individuals requiring access to information and information systems sign ac-cess agreements, prior to being granted access. Access agreements must be re-signed, by all parties, when agreements have been updated. Access agreements are reviewed at least https://www.dhs.gov/homeland-security-presidential-directive-12 https://www.dhs.gov/homeland-security-presidential-directive-12 annually.

6. Ensure that DHS Components train users on rules of behavior and that each user signs a rules of behavior agreement within 5 business days of first accessing a DHS system

7. Ensure that wireless mobile devices are not tethered or otherwise physically or wirelessly connected to the DHS-wired core network, without the prior written consent of the Authoriz-ing Official (AO). For additional requirement details see NIST SP 800-124, Revision 2 (DRAFT), “Guidelines for Managing the Security of Mobile Devices in the Enterprise,” March 2020 and NIST SP 800-121 Revision 2, “Guide to Bluetooth Security,” May 2020.

a) Ensure that pairings are made only between approved (Bluetooth, wireless, mo-bile, etc.) devices.

b) Disable Bluetooth functionality when not in use. See NIST SP 800-121 Rev. 2, “Guide to Bluetooth Security” for additional requirement details.

c) Ensure that devices are configured for manual pairing and prompt the user to au-thorize any incoming connection requests; auto pairing may not be implemented.

d) Maintain devices in non-discoverable mode, except during device pairing.

e) Pair devices to receivers, in personally owned vehicles, for voice communication as approved by the AO.

f) Ensure that devices use low power to minimize the range of communication.

8. Ensure DHS Components identify and implement appropriate operational and technical con-trols to limit unauthorized tracking or targeting of radio-frequency identification (RFID)-tagged items, when these items are expected to travel outside of the Component’s physical perimeter.

9. Employ encrypted virtual private networks (VPNs) to enhance confidentiality and integrity over remote connections. See NIST SP 800-77, Revision 1, “Guide to IPsec VPNs,” June 2020.

10. Ensure that multiple or split tunnel communication paths are not enabled on devices except where authorized using the Trusted Internet Connection (TIC) 3.0 modernization guidance, Split Tunneling can allow trusted applications to be split from the VPN tunnel, and managed by the Cloud Access Security Broker, with the management of the connection for compliance control managed by the broker at the management point.

11. Ensure that Personally Identifiable Information (PII), law enforcement sensitive information, and security sensitive information complies with all DHS requirements for sensitive systems, including strong authentication. Strong authentication is accomplished by means of VPN or equivalent encryption and two-factor authentication. The risk assessment and security plans (SP) must document any remote access of PII, and the approval of remote access is approved by the DHS Authorizing Official (AO) prior to implementation. " See FIPS 140-2, FIPS 140-https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r2-draft.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r2-draft.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2-upd1.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2-upd1.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf

3, NIST SP 800-53, Revision 5, and NIST SP 800-63.

a) Additionally, remote access of Personally Identifiable Information (PII), law en-forcement sensitive information, and security sensitive information does not per-mit the download and remote storage of information unless the requirements for the use of removable media with sensitive information have been addressed. All downloads follow the concept of least privilege and are documented in the Secu-rity Plan (SP). See FIPS 199 and NIST 800-53 Revision 5 as a part of the DHS security baseline, Attachment CC of this document.

12. Shall display a warning banner, specified by the DHS CISOD, for all internal DHS systems.

a) Provide security and privacy statements, at every entry point, for systems accessi-ble to the public.

b) Concur that the use of DHS information systems by any user (including DHS per-sonnel, contractors, and others working on behalf of DHS) is subject to monitor-ing or search at any time. By completing the authentication process, the user acknowledges their consent to monitoring and acknowledges that they have no ex-pectation of privacy for their use of or for information stored in such systems.

c) Concur that the use of Government office equipment and DHS systems/computers constitutes consent to monitoring and auditing, of the equipment/systems at all times. Monitoring includes the tracking of internal transactions and external trans-actions such as Internet access. It also includes auditing of stored data on local and network storage devices as well as removable media.

(AT) Awareness and Training Control Family

All levels of DHS management must ensure employees, contractors, vendors, and other third-party entities are informed of their security responsibilities and the need to attain required continued education relevant to information security, their position within DHS, and their Program Offices. Maintaining a level of due diligence, ensures that key objectives of an ef-fective Information Security Program are attained. All employees and contractors must un-derstand their roles and responsibilities and become adequately trained to perform them, thus, ensuring the protection of the confidentiality, integrity, and availability of DHS infor-mation systems and the information they contain.

All DHS users and personnel, including contractors, who leverage DHS information Systems have a responsibility to consider their responsibilities for any system they access and be aware of all security risks associated with their use and management of that system. Mecha-nisms must be established to verify and track security awareness and specialized security training for personnel who have been designated as having significant security responsibilities (i.e., Federal Workforce Assessment surveys).

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf

DHS’s awareness and training requirements, at a minimum, shall:

AT 1: Cybersecurity Awareness and Training Program

1. Components must establish a Cybersecurity Awareness and Training Program for users of DHS information systems.2. Components prepare and submit a Cybersecurity Awareness and Training Annual Implementation Plan (to include role-based training) each fiscal year to the DHS Enterprise Cybersecurity Awareness and Training Program by the end of the first quarter.

2. The DHS CISO will provide oversight of Component Cybersecurity Awareness and Training Program Plans and Component Cybersecurity Awareness and Training Annual Implementa-tion Plans. The DHS CISO will review both plans annually.

3. Components prepare and submit ad hoc cybersecurity awareness reports with content, fre-quency, format, and distribution at the request of the DHS CISO.

AT 2: Initial Basic and Annual Refresher Cybersecurity Awareness Training

1. DHS personnel, contractors, or others working on behalf of DHS (i.e., employees, detailees, military) accessing DHS systems will receive Initial Basic Cybersecurity Awareness Training which, at a minimum, must cover basic cybersecurity literacy and concepts, terms, threats, and rules for using a system(s). Personnel must complete Initial Basic Cybersecurity Aware-ness Training within 5 business days of first accessing a DHS system. Components will take appropriate actions, up to and including suspension of the user account, to ensure training completion.

2. DHS personnel, contractors, or others working on behalf of DHS (i.e., employees, detailees, military) accessing DHS systems will receive Annual Refresher Cybersecurity Awareness Training (CSAT) in security awareness and accepted security practices. If Annual Refresher Cybersecurity Awareness Training is not completed, Components will take appropriate ac-tions, up to and including suspension of the user account, to ensure training completion.

Components shall have the flexibility to determine whether annual refresher CSAT comple-tion will be tracked based on fiscal year or calendar year.

3. Components must maintain sufficient Initial Basic and Annual Refresher Cybersecurity Awareness Training records as produced by the Component's Learning Management System (LMS), to include compliant and non-compliant CSAT users. Records must be maintained in accordance with Office of the Chief Human Capital Officer (OCHCO) or National Archives and Records Administration (NARA) training records retention requirements.

4. User accounts and access privileges, including access to email, is temporarily disabled for those DHS employees who have not completed Annual Refresher Cybersecurity Awareness Training, unless a waiver is granted by the Component’s Chief Information Security Officer (CISO) or Information Systems Security Manager (ISSM). The account will only be re-ena-bled to allow the user to complete the CSAT module and course completion will be verified in the LMS.

5. Components must provide CSAT (Initial Basic CSAT and Annual Refresher CSAT) training completion statistics by April 30th, July 31st, and October 1st to the Enterprise Cybersecurity Awareness and Training Program using the designated format.

AT 3: Role-based Training

1. DHS personnel, contractors, or others working on behalf of DHS (i.e., employees, detailees, military) with significant cybersecurity responsibilities must receive specialized training as defined in NIST SP 800-181 or DHS minimum role-based standards prior to obtaining access to the system(s) containing sensitive information. Examples of minimum roles include: Infor-mation Systems Security Officers (ISSO), Information Systems Security Managers (ISSM), Authorizing Official (AO), System Owners (SO), System Administrators, etc.). Individuals designated as having a role with significant cybersecurity responsibility must complete re-fresher training each fiscal year, thereafter.

Primary role-based training will be based on the NIST SP 800-181 requirements, followed by DHS specific training requirements for roles with significant cybersecurity responsibility.

2. Components must maintain sufficient Role-based Training records as produced by the Com-ponent's Learning Management System (LMS), to include compliant and non-compliant us-ers. Records must be maintained in accordance with Office of the Chief Human Capital Of-ficer (OCHCO) or National Archives and Records Administration (NARA) training records retention requirements.

3. Components must provide role-based training completion statistics by April 30th and Octo-ber 1st to the Enterprise Cybersecurity Awareness and Training Program using the desig-nated format.

Privacy

1. DHS Components will administer basic privacy training annually and targeted, role-based privacy training for personnel having responsibility for PII or for activities that involve PII annually. See the (PT) Personally Identifiable Information Processing and Transparency Control Family for additional details.

2. Ensure managers and users of DHS information systems are made aware of the security and privacy risks associated with their activities and of the applicable laws, Executive Orders, di-rectives, policies, standards, instructions, regulations, and procedures related to the security of DHS information systems.

3. Components develop, implement, and update a comprehensive Privacy training and aware-ness strategy aimed at ensuring that personnel understand privacy responsibilities and proce-dures.

4. DHS Components ensure that personnel annually certify (manually or electronically) ac-ceptance of responsibilities for privacy requirements.

Rules of Behavior & General Information

1. Ensure that DHS Components train users on rules of behavior and that each user signs a rules of behavior agreement prior to being granted user accounts or access to information systems or data.

2. Promote collaboration on information security training efforts across the Department through the DHS Information Security Training Working Group (ISTWG) and share information on Component-developed training activities, methods, and tools, thereby reducing costs and avoiding duplication of effort. The Information Security Training Working Group is chaired by the DHS Enterprise Cybersecurity Awareness and Training Program Manager.

3. Ensure DHS Components abide by security training requirements listed in this directive, and that they prepare and submit information security awareness reports (including content, fre-quency, format, and distribution) for the DHS CISOD, as required.

(AU) Audit and Accountability Control Family

An audit is an independent review and examination of records and activities to assess the ade-quacy of the information system’s controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in those controls, policies, or procedures. Accountability is the principle that an individual is entrusted to safeguard and control information/data, equipment, keying material, and is accountable to management for the use/misuse or compromise of that information system or resource.

The audit and accountability control family address the ability to maintain a record of system application and user activity. In conjunction with the appropriate tools and procedures, audit-ing can assist in detecting security violations, performance problems, and application flaws.

This control family also serves as an insurance policy, ensuring that there are mechanisms in place to track and associate user, process, and system activity to events.

Whenever there is a deviation from the prescribed mode of operation, an examination of the audit and accountability controls can serve as a launch point to determine factors that may have caused this deviation or failure.

DHS’s audit and accountability requirements, at a minimum, shall:

1. Develop, adopt, and adhere to a formal documented program for the monitoring, management, and review of system, application, network, and user activity. See

OMB M-21-31.

2. Develop standards and procedures to guide the implementation and management of audit controls and records.

3. Create, protect, and retain information system audit records to the extent needed to https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf enable the monitoring, analysis, investigation, and reporting of unlawful, unauthor-ized, or inappropriate information system activity.

4. Ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions.

5. Provide audit record generation capability for relevant or auditable events identi-fied by DHS. Per NIST definition, a relevant event is an occurrence (e.g., an au-ditable event or flag) considered to have potential security implications to the sys-tem or its environment that may require further action (noting, investigating, or re-acting).

6. Audit records are sufficient in detail to facilitate the reconstruction of events if compromise or malfunction occurs or is suspected. Audit records are reviewed as specified in the SP. The audit record contains at least the following information:

• Identity of each user and device accessing or attempting to ac-cess the system

• Time and date of the access and the logoff

• Activities that might modify, bypass, or negate information secu-rity safeguards

• Security-relevant actions associated with processing

• All activities performed using an administrator’s identity

7. When available, Components ensure implementation of enterprise auditing and re-cording of sessions (keystroke and graphical).

8. Review audit records monthly for financial systems or for systems hosting or pro-cessing PII. Unusual activity or unexplained access attempts are reported to the System Owner and to the Component CISO/ISSM. Ensure DHS systems’ audit records and audit logs are protected from unauthorized access, modification, or de-struction.

9. Record and retain audit logs in accordance with the DHS systems’ Record Sched-ule or with the DHS systems’ Record Schedule. At a minimum audit trail records are maintained online for at least 90 days. Preserve audit trail records for a period of seven (7) years as part of managing records for each system to allow audit infor-mation to be placed online for analysis with reasonable ease. DHS allocate appro-priate audit record storage capacity in accordance with these requirements.

10. Ensure DHS evaluates the system risks associated with extracts of PII from data-bases. If the risk is determined to be sufficiently high, a procedure is developed for logging computer-readable data extracts. If logging these extracts is not possible, this determination is documented, and compensating controls identified in the SP.

(CA) Assessment, Authorization, and Monitoring Control Family

The assessment and authorization (A&A) process is implemented to ensure compliance with federal laws and regulations and is critical to minimizing the threat of breaches. Security and privacy assessments are conducted to determine the extent to which the controls are imple-mented correctly, operating as intended, and producing the desired outcome with respect to meeting the security and privacy requirements for the information system. Authorization is the process of accepting the residual risks associated with the initial and continued operation of DHS systems and granting approval to operate for a specified span of time. The Information Security Continuous Monitoring (ISCM) process is established to maintain an ongoing aware-ness of information security, vulnerabilities, and threats to support DHS risk management deci-sions. Control assessments evaluate the risk associated with the operation of a system and al-low the Authorizing Official to ensure the system is operating at an acceptable risk prior to au-thorizing.

DHS’s assessment, authorization, and monitoring requirements, at a minimum, shall:

1. Categorize information sensitivity in compliance with FIPS 199 as the basis to implement the appropriate DHS NIST 800-53 baseline controls. See Attachment CC for details.

a) DHS Components assign the highest water mark for the impact levels (high, moderate, low) measured for the combined security objectives (confidentiality, integrity, and availability) for each DHS information system. DHS Components apply NIST SP 800-53, Revision 5, controls as tailored specifically to the se-curity objective and impact level determined as described in NIST SP 800-53b, section 2.4.

b) DHS Components implement the DHS Control Baseline, see Attachment CC for details on ODVs, and referencing FIPS Pub 200, Minimum Security Re-quirements for Federal Information, and Information Systems, based on the data’s highest FIPS 199 impact level established for the combined security ob-jectives (confidentiality, integrity, availability).

i) DHS Components conduct their information systems security reviews in accordance with both FIPS 199 and NIST SP 800-53, Revision 5, for speci-fication of security controls. NIST SP 800-53A are used for assessing the effectiveness of security controls and for quarterly and annual FISMA re-porting.

(1) All FISMA documentation must be consistent and up to date. ISCM waivers for FISMA reporting will be considered for the following types of systems:

(a) Software Only (internally hosted cloud environment)

(b) Software as a Service (SaaS) https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53B.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53B.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar5.pdf

(c) FedRAMP P-ATO systems

(d) “Stand Alone” systems

2. Ensure that only authorized systems including, but not limited to, workstations, servers, cloud computing applications, software applica-tions, mobile devices, networks, and data repositories have an authoriza-tion to operate (ATO) in accordance with DHS’s business needs. See the DHS Security Authorization Guide (SAG) for additional details.

3. Components are required to leverage automated tools (e.g., CSAM) for system authorization for analysis but must also provide manual expert analysis through the package review process. Automated tools will also provide initial data categorization and security responses, focusing on tagging and managing access to sensitive documents.

4. Artifacts in support of new ATOs are not older than 12 months. Existing artifacts are not valid beyond the life of any current ATO unless the sys-tem is enrolled in ongoing authorization program, requiring continuous assessment to produce the annual assessment SAR and ATO renewal.

See the DHS Ongoing Authorization Guide for additional details.

a) DHS Components assign a common controls package for sys-tems providing common control infrastructure (e.g., hosting provid-ers such as cloud IaaS). DHS Components assign a common control provider to share controls between systems (e.g., at hosting centers).

The authorization package of those common controls is shared with those operating under the controls in accordance with the individual service level agreements and with those leveraging those services.

i) DHS Common Control Policy

ii) FedRAMP Control Baselines

a) For systems not entering Ongoing Authorization (OA) Program, Compo-nents authorize DHS systems at Initial Operating Capability (IOC) and every three (3) years thereafter, or sooner, whenever a major change occurs.

b) For Systems entering the Ongoing Authorization (OA) Program, OA Components authorize DHS systems at Initial Operating Capability (IOC), through submission of an OA Admission Letter and renewed thereafter annually as a part of the annual assessment approval, with 100% of controls tested within an 3 year period, in accordance with OMB A-130, NIST guidance and DHS On-going Authorization Methodology. (See DHS Security Authorization Templates.)

c) DHS enterprise services are required to provide a catalog of common con-trols that have been assessed and authorized by the AO of that service.

d) Components leveraging FedRAMP Provisional Authority to Operate ( P- ATO) Authorizations, Agency Authorized Systems, or sponsor an agency http://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/PublishingImages/Pages/ComplianceDocs/Security%20Authorization%20Process%20Guide%20v14.1.pdf https://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/_layouts/15/WopiFrame.aspx?sourcedoc=%7b8553F666-7A55-4F87-94C2-15423D82F5D7%7d&file=Common%20Controls%20Implementation%20Guide.docx&action=default&DefaultItemOpen=1 https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx https://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/CISO%20ALL%20Documents/DHS%20OA%20Methodology%20v1_8_Final.pdf https://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/CISO%20ALL%20Documents/DHS%20OA%20Methodology%20v1_8_Final.pdf https://www.dhs.gov/publication/dhs-security-authorization-templates https://marketplace.fedramp.gov/#!/products?sort=productName&authorizationType=Agency https://marketplace.fedramp.gov/#!/products?sort=productName&authorizationType=Agency https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Playbook.pdf authorization for a cloud system, are responsible for reviewing, monitoring and, or maintaining all common activities for that CSP. This includes:

i) In the initial DHS ATO process, Components must assess the risk of the sys-tem and review CSPs documents (e.g., System Security Plan (SSP), Security Assessment Report (SAR)) as a part of their security package in order to vali-date the control implementations meet DHS requirements. DHS must decide if the risk is acceptable, and if the system meets DHS requirements. DHS must review and determine if FedRAMP P-ATO Cloud Service Provider’s baseline controls, that are not customer responsible controls, meet, or exceed, DHS requirements and whether they are inheritable by the component.

ii) Responsibilities for DHS agency ATOs include monitoring all Cloud Service conmon activities (both provider and agency instance) according to the DHS Security Authorization Guide based on FedRAMP requirements (e.g., monthly vulnerability scans, POA&M and vulnerability management, signifi-cant change requests, corrective action plans, etc.,).

(1) FedRAMP Agency Authorizations and DHS ATOs: DHS is responsible for coordinating conmon with the cloud service provider for review

(2) FedRAMP Joint Authorization Board Provisional Authority to Operate

(P-ATO): DHs is responsible for reviewing the monthly conmon one pager available in the public customer facing folder.

iii) All DHS cloud service ATOs must follow and adhere to FedRAMP require-ments. See FedRAMP Authorization Roles and Responsibilities for additional details.

2) Assess security and privacy controls periodically (e.g., Annual Assessment) in DHS information systems to determine if the controls are implemented according to current NIST SP 800-53, Revision 5, requirements.

3) Develop and implement POA&Ms designed to correct deficiencies and reduce or eliminate vulnerabilities in DHS information systems.

a) Develop plans for vulnerability remediation management and POA&Ms that adhere to federal timeline requirements outlined below, un-less otherwise noted.

b) Item identified during an assessment (source of weakness) must be se-lected for all POA&Ms. This may include, but is not limited to, annual assessments, security assessment findings that produce a Security Assess-ment Report (SAR), audit findings [OIG, Government Accountability Of-fice (GAO)], OMB Circular A-123 Reviews, IT Acquisition Reviews (ITARs), Enterprise Architecture Center of Excellence (EA COE), man-agement decisions, and Information Security Vulnerability Management (ISVMs).

https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Playbook.pdf http://dhsconnect.dhs.gov/org/comp/mgmt/ocio/ciso/PublishingImages/Pages/ComplianceDocs/Security%20Authorization%20Process%20Guide%20v14.1.pdf https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Roles_and_Responsibilities_for_FedRAMP_CSPs_and_Agencies.pdf https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Roles_and_Responsibilities_for_FedRAMP_CSPs_and_Agencies.pdf https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/memoranda/2016/m-16-17.pdf

c) If not remediated within 30 days of detection, POA&Ms must be cre-ated for all unremediated technical findings, as cited in the most current 4300A Attachment H Plans of Actions and Milestones (POA&M) Guide, hereafter known as Attachment H, POA&M Guide, and tracked on the Weakness Remediation Scorecard, including ISVMs, and the required timeline for remediating technical findings, such as Software vulnerabili-ties and misconfigurations outlined, unless otherwise noted, are as fol-lows:

i) Critical vulnerabilities associated with DHS systems must be remediated within 15 days of initial detection. [Binding Operational Directive (BOD) 19-02 (April 29, 2019)]

ii) High vulnerabilities associated with DHS systems must be remediated within 30 cal-endar days of detection.

iii) Moderate vulnerabilities associated with DHS systems must be remediated within 90 calendar days of detection.

iv) Low vulnerabilities associated with DHS systems must be remediated within 180 calendar days of detection.

4) POA&M technical remediations are coordinated between the system ISSO, System Administrator/Engineer responsible for the maintenance and configuration of the system, and the System Owner.

a) ISSOs track and coordinate the completion of milestones carried out by the Sys-tem Administrator/Engineer responsible for the system maintenance and configuration of the system impacted by the finding.

b) The responsible System Admin/engineer must provide the root cause for each POA&M, see DHS 4300Aattachment H Plan of Action and Milestones (POA&M) Guide for instructions and for A-123 related findings see the Root Cause template here, ISSMs track and validate the evidence of POA&Ms closures which impact all the systems under their purview.

c) Control Validation (meaning the testing of any impacted controls) after POA&M remediation have been completed, and the evidence of testing is provided for POA&M closure. See NIST SP 800-53A for details on required testing and evidence methods and guidelines.

d) POA&M closures require validation of remediation evidence submitted (e.g., re-mediation scans, configuration validation, hardware replacement, process validation, at-testation, etc.) prior to closure.

e) The Information System Security Manager (ISSM) of the system is responsible for verifying this evidence and…