DHS Information Security Performance Plan

(1)

Fiscal Year 2014

DHS Information Security Performance Plan

January 27, 2014

Version 1.0

This document was prepared for authorized distribution only. Department of Homeland Security

(2)

List of Figures

Figure 1: Examples of Performance Plan Strategic Inputs ... 1

Figure 2: Inventory Refresh Phases ... 10

Figure 3: Example of an ISCM Program ... 11

Figure 4: Ongoing Auththorization Process ... 23

Figure 5: Document Review Process Flowchart ... 24

Figure 6: Document Review Methodology Steps ... 25

Figure 7: POA&M Process Map ... 34

Figure 8: FY14 ISCM FISMA Scorecard ... 43

Figure 9: FY14 SPM FISMA Scorecard ... 44

Figure 10: FY14 Trend Chart ... 45

Figure 11: Sample Cover Sheet ... 71

Figure 12: Sample SP Checklist ... 71

Figure 13: Sample CP Checklist ... 72

Figure 14: DHS NIST RMF Workflow ... 86

(7)

List of Tables

Table 1: Asset Definitions ... 8

Table 2: Current and Future ISCM Capabilities ... 12

Table 3: Continuous Monitoring Capability Groups ... 14

Table 4: Data Elements for ISCM Metrics ... 15

Table 5: FY14 Overall ISCM Score Contributions ... 46

Table 6: FY14 Overall SPM Score Contributions ... 47

Table 7: POA&M Assurance Checklist ... 74

Table 8: NIST Reasonableness Resource Matrix ... 81

Table 9: DIACAP Reasonableness Resource Matrix ... 85

Table 10: Metric POCs ... 88

Table 11: FY14 CCE Settings... 91

Table 12: Points of Contact... 92

(8)

1. Executive Summary

The annual Department of Homeland Security (DHS) Information Security Performance Plan defines

performance requirements, priorities, and overall goals for all DHS Components throughout the current Fiscal Year (FY). It is a tactical interpretation of numerous strategic inputs including; federal mandates, interagency standards, and DHS-specific policies and initiatives. Performance Plan outputs also serve to communicate security posture and risk at the Component and Enterprise levels for remediation and strategic decision-making.

The FY14 Performance Plan addresses an array of areas of information security through selected metrics: Inventory of Systems & Assets, Information Security Continuous Monitoring (ISCM), Security Management, and Enterprise and Chief Information Officer (CIO) initiatives. ISCM is of particular importance in FY14 as DHS looks to leverage the National Protection and Programs Directorate (NPPD) Federal Network Resilience’s (FNR) Continuous

Diagnostics and Mitigation (CDM) Program for purchasing security tools and services, therefore bolstering the

capabilities across DHS while also becoming a more technological homogenous department. As in FY13, metrics will focus more on capability effectiveness rather than on implementation as DHS looks to mature the ability to provide more real-time and more expansive tactical data

to risk executives and security leadership throughout DHS. Awareness of our asset

vulnerabilities more often equates to better prepared Information Technology (IT) environments, and ultimately a more secure DHS.

Progress remains measured by target levels of compliance and FY14 will continue to emphasize a focus on the asset level rather than the system level. With this process, risk is assumed by a Component rather than by a particular system. Overall, the FY14 Performance Plan echoes much of what was underscored in FY13 while improving upon the effectiveness of several metrics. These improvements are meant to promote more nuanced and accurate results and thereby better understanding of the information security at DHS and its Components. New in FY14, the scorecard will emphasize some themes which DHS is looking to grow, to include Whitelisting, Ongoing Authorization (OA), and completeness or ‘coverage’ of Component scanning efforts (i.e., Scan Coverage). All of the metrics and topics described in this

Performance Plan align either directly or indirectly with federal requirements and have been researched and incorporated in such a way as to help maintain DHS’ leadership role in federal government cyber security.

Figure 1: Examples of Performance Plan Strategic Inputs

(9)

2. Introduction

2.1 Purpose

The Performance Plan describes annual requirements, priorities, and procedures applicable to Components in a given fiscal year. Metrics and a monthly scorecard are used to gauge progress toward Departmental goals. It also serves as a roadmap for future initiatives in order to

encourage forethought and innovation amongst Components.

FY14 continues the federal trend of measuring Federal Information Security management Act (FISMA) compliance in percentages but also markedly focuses on the role of specific risks at play within the Department. FY14 introduces mechanisms for correlating data from different security vantage points in order to support certainty and integrity of scanning and data collection efforts. FY14 also will represent new metrics on the scorecard as informational concepts to promote the more efficient use of data derived from mandated security activities; for instance, raising the visibility of the newly codified Ongoing Authorization program with an informational maturity metric. This metric is meant to promote OA as a more effective method for keeping security leadership aware of the risks and vulnerabilities associated with information systems by leveraging ISCM monthly data, inheritance of controls, and breaking the arbitrary mold of 3-year Authority to Operate (ATO)s. Other examples of promoting efficiency and correlation activities is introducing a mode of performing application Whitelisting which highlights unauthorized existence of applications in Component environments, and Information Security Vulnerability Management (ISVM) correlation against monthly ISCM patch and Common Vulnerability Enumeration (CVE) data. Approaching risk management in this manner provides more accurate insight into the threats faced by both DHS and the government at large.

The FY14 Performance Plan draws from several key sources and initiatives for guidance including:

• Maturing Information Security Continuous Monitoring • Prioritizing information security actions

• Addressing Government Accountability Office (GAO) High Risk Priorities

• Remediation of OIG-14-09: Evaluation of DHS’ Information Security Program for Fiscal Year 2013

• Supporting the DHS Information Security Strategic Plan

(10)

2.2 Scope

The FY14 Performance Plan applies for the entirety of the fiscal year to all DHS Components and the operational1 information systems for which they are responsible. Components are required to maintain FISMA Systems within the Information Security Office (ISO) FISMA Compliance Tool and also submit monthly data reflecting the security posture of their organizations to the DHS ISO for analysis. Data submissions are structured around metrics associated with Departmental goals2. The Performance Plan is not intended to dictate the processes or methodology by which Components obtain the data necessary to generate these metrics, however, it does establish the precise type of data and format in which metrics must be reported which may significantly influence data collection methods. Metrics and associated requirements may differ depending on characteristics of a given system, such as whether it is Sensitive but Unclassified (SBU), National Security System (NSS), or a Chief Financial Officer (CFO) designated system3. Specific disparities are documented in Appendix A for applicable metrics. Security Operations Centers (SOCs) within the DHS Enterprise are also required to report information pertaining to effective visibility into security events and management of reported incidents.

The DHS Executive FISMA Scorecard is a consolidated Department view of all individual Component metrics. It is used to communicate overall security posture to DHS executives for strategic decision-making, as well as emphasize areas for improvement to Component-level security compliance and operations personnel. Furthermore, it integrates DHS and federal priorities in a single mode of communication for internal and external use.

1

Only systems designated as operation in the current FISMA Compliance Tool are subject to Performance Plan reporting requirements. Systems in implementation and modification status as per the System Engineering Life Cycle (SELC) are also considered operational.

2_{ISO expects that some adjustments will be necessary once NIST 800-53 revision 4 is released within the IACS tool.}

Until that time, however, the Department will continue to adhere to revision 3.

3

CFO-designated systems have additional information security requirements beyond the scope of the FY14 Performance Plan.

(11)

2.3 Audience

The Performance Plan is applicable to any DHS federal employee or contractor involved in IT compliance, security, architecture, and/or risk management. The DHS Chief Information

Security Officer (CISO) is the primary owner of the Performance Plan, responsible for managing necessary updates or modifications. The DHS CISO Council, comprised of CISOs representing each DHS Component, is the authorizing body for the content of the Performance Plan. The primary output of the requirements contained in the Performance Plan is the DHS Executive FISMA Scorecard, which is used to communicate broadly to senior DHS executives, such as the CIO, as well as federal oversight entities, such as the Office of the Inspector General (OIG) and the Office of Management and Budget (OMB).

DHS chairs and participates in several working groups that serve as forums for developing and disseminating information that can help Components meet current reporting requirements and develop new capabilities for future requirements to include:

• Compliance Working Group (CWG) – The CWG is a forum used specifically to address issues and events related to Component FISMA Scorecard performance, FISMA Inventory, Compliance Tools, and Compliance related activities. This includes clarification of requirements, best practices for collecting and reporting information, and relevant changes to standard procedures.

• Continuous Monitoring Working Group (CMWG) – The CMWG address the procurement, implementation, and operation of enterprise ISCM solutions and how they can best be leveraged by Components.4

• Enterprise System Security Working Group (ESSWG) – The ESSWG develops and vets security requirements, policy, and architecture for all DHS enterprise service offerings.

• Ongoing Authorization Working Group (OAWG) – The OAWG is an interagency working group, co-chaired by DHS and the Department of Health and Human Services (HHS) that works to develop a strategy for transitioning the traditional periodic Security Authorization (SA) process to an ongoing process, utilizing capabilities such as common controls and continuous monitoring.

• Joint Continuous Monitoring Working Group (JCMWG) – is the interagency body for Continuous Monitoring collaboration, cooperation, and coordination; the principal venue by which the Executive Branch synchronizes Continuous Monitoring policy across the National Security Systems and non-National Security Systems.

4

The CWG and CMWG may occasionally combine as one meeting depending on the time of year, meeting resources, and content of the meeting.

(12)

2.4 Goals and Objectives

In FY14, the Department intends to 1) continue its security approach toward risk management through an evolved Scorecard, 2) mature information security continuous monitoring capabilities and effectiveness across the enterprise, and 3) bolster correlation, provide more efficient

processes, and promote enterprise-wide security tool standardization. Comprehensive risk scoring and near real-time vulnerability and IT asset awareness are future goals that will become more feasible as DHS processes and capabilities mature.

FY14 metrics support quarterly and annual FISMA reporting requirements. ISCM data is also used to meet required monthly Extensible Markup Language (XML) data feeds to OMB through its CyberScope application. As of October 2013, CyberScope XML feeds are required to be submitted for all Components and will be verified by FNR.

The most significant improvements and changes for FY14 are:

• Concentrating information security continuous monitoring metrics focus on effectiveness versus implementation.

o Vulnerability Management transitions to measuring critical and high vulnerabilities per asset.

o Configuration Management expands to require United States Government Configuration Baseline (USGCB) settings for additional platforms beyond workstations.

o Information Security Vulnerability Management, previously “Patch Management”, will now assess vulnerability data to ensure that required

assets/systems were patched for all Alerts and two random Bulletins (one related to workstations and one related to servers).

• Implementation of an Ongoing Authorization Programs at the Enterprise level. • Implementation of an Enterprise Whitelisting Program by leveraging current Security

Content Automation Protocol (SCAP) data.

• Clarifying the relationship of External Information Systems (EIS), Cloud Service Providers (CSPs), and Cloud Tenant Minor Applications (CTM), and information security policy.

The FY14 metrics as outlined in Appendix A are intended to:

• Integrate in-depth organizational monitoring across the layers of defense;

• Introduce a measurable whitelisting effort to increase scrutiny of application level security;

• Correlate data sources in order to bolster integrity of Component vulnerability scanning; • Grow DHS’s version of the OMB-endorsed (M 14-03) Ongoing Authorization concept; • Eliminate critical and high vulnerabilities;

• Achieve automated asset inventory reporting;

• Measure the effectiveness of organization Plan of Action & Milestone (POA&M) management and Security Authorizations;

• Ensure accurate, real-time automated data;

• Maximize the use of DHS Enterprise License Agreements (ELAs); and • Collect information that can be used to determine true measures of risk at the

(13)

2.5 Strategy

In addition to being a representation of Departmental information security initiatives, the Performance Plan supports federal directives, congressional requirements, National Institute of Standards and Technology (NIST) guidance, and CIO FISMA priorities. DHS priorities align with federal mandates and interagency standards, in addition to focusing on DHS-specific security needs. FY14 metrics are grouped in several categories:

• Inventory of Systems and Assets – Ensuring visibility and accountability for all

information systems and assets, such as workstations and servers, is foundational to the completeness and integrity of nearly all other metrics. Inventory metrics reflect whether Department requirements are being met comprehensively.

• Information Security Continuous Monitoring – ISCM metrics help to maintain an accurate picture of an organization’s real-time security risk posture by consistently leveraging management tools, security controls, and prioritized risk mitigation. • Security Management – Metrics addressing longstanding security practices, many of

which are federal compliance requirements.

• Security Operations Center – A continuing initiative from FY12, DHS is seeking to better monitor and support the maturation of its SOC and incident response capabilities. FY14 metrics focus on timely Security Event Notice (SEN) management and verifying ISVM management.

• Enterprise Solutions – Enterprise Solution metrics are not system specific, but rather measure how effectively enterprise security initiatives are deployed by large programs and/or entire Components.

The metrics that make up each group are collectively used to form an Executive FISMA

Scorecard broken up into two groups: Information Security Continuous Monitoring and Security Processes. The Executive FISMA Scorecard, in turn, feeds into Component-level scorecards, reports at the system-level, and reports at the asset level. This tiered approach maximizes visibility into all levels of the Department’s security posture. They FY14 Performance Plan is designed to address each metric grouping, while also addressing how the DHS ISO and Components validate security compliance and risk management processes.

2.6 Verification and Validation

Although Components assume ultimate responsibility for all data submitted to DHS ISO, quality checks and validation processes exist to assist with compliance and comprehensive risk

management. Tools, review processes, and targeted Quality Assurance (QA) all work together to provide validation and verification for Department activities.

(14)

3. Inventory Management

In order to support the DHS mission, it is vital that the Department have an accurate accounting of all systems and assets within the Department’s boundary. Unaccounted systems pose greater risk due to the uncertainty of ownership, maintenance, and compliance with federal mandates, directives, and policies. The goal of monitoring assets across the entire Department is to ensure that each facet of an information system poses the minimum possible risk. Ensuring security at the smallest level of each system enhances security for the enterprise as a whole.

3.1 System Inventory

Accurate system and asset counts are the foundation upon which FY14 metrics are calculated. In FY14, Components scan, monitor, and report all systems (SBU, Classified, and Mission

Essential) and assets to the Office of the Chief Information Officer (OCIO). In FY14, mobile devices are included within the scope of assets but do not contribute to the Scorecard metrics. The ISO Inventory Management Team (IMT) continues to discover and maintain Components’ inventories of systems through the Annual Refresh process, further detailed in section 3.4: ISO Inventory Reviews.

3.2 Asset Inventory

Components are required to report all Hardware and Software Assets within their organization in order to accurately maintain a full Inventory for the ISCM Program that supports all FISMA related activities as defined in the RMF.

A Hardware Asset – often referred to as simply an ‘asset’ in this text – is defined as:

any addressable device that can be connected to a DHS Network and used in the course of operational or business activities. Hardware Assets include, but are not limited to: laptops, workstations, servers, virtual computing platforms, network devices, mobile devices, printers, and communications media.

A Software Asset is defined as:

any application, excluding an operating system, deployed on a Hardware Device. Not all assets in the Department’s inventory are required to be scanned and reported to the ISO Continuous Monitoring (CM) Team. These requirements are fully defined in Appendix A and Table 1: Asset Definitions. In Scope Assets represent the entire population of a Component’s Hardware Asset Inventory that should be reported through the Asset Inventory form on the FISMA Reporting SharePoint Site (see Metric 1: In Scope Assets). All required assets that are scanned and reported to ISO are classified as either ‘Managed’ or ‘Invalid’ assets. Managed assets are those reporting ISCM data on a monthly basis.

Managed Assets serve as the scoring population for ISCM metrics. Invalid assets have an invalid FISMA Identifier (ID) or are missing a unique hostname. These two fields are “key identifiers” for all assets. Invalid assets populate a Component’s Asset Exception List and are reported back to the Component by the ISO CM Team. For more information on Asset

Classification, see the Asset Classification White Paper located on the FISMA Reporting SharePoint Site.

(15)

Term Definition Possible implications

In Scope Asset A device that is or should be connected to the unclassified network and maintains an IP address.

Should be scanned for monthly ISCM reporting and will be scored for “Scan Coverage.”

Dormant Asset Those devices that may be stored for mission related purposes and are not currently in use or assigned.

Considered “Out of scope” and will not be scored for any purposes. ISO will still track these devices.

Mobile Asset Devices that currently cannot be scanned due to enterprise technology availability. (e.g. smartphones, tablets, or Universal Serial Bus (USB) devices).

Considered “Out of scope” and will not be scored for any purpose. ISO will still track these devices.

Invalid Asset A scanned asset that is 1) missing or has an invalid FISMA ID and/or 2) missing a hostname.

Invalid assets cause an exception and are NOT imported into the

Continuous Monitoring Database (CMDB)

Managed Asset A scanned asset that contains a 1) valid FISMA ID and 2) hostname.

Managed assets make up the scoring population for the Scorecard and can be called “Operational Assets” (comparable to “Operational Systems”).

Identified Assets A Managed Asset that is fully defined by the OS Common Platform Enumeration (CPE) (e.g. Microsoft Windows 7, Solaris, CISCO Internetwork Operating System (IOS), and Windows Server 2003). These are also called “Hardware Managed Assets.”

In order to properly assign requirements to an asset, it must be identified. These assets have been credential scanned.

Unidentified Assets A Managed Asset that cannot define the OS CPE OR is defined as a Windows OS Platform but contains an IP as a hostname. IP hostnames that are Dynamic Host

Configuration Protocol (DHCP) create an unstable asset inventory that constantly shifts and changes.

Unidentified assets will

automatically fail all ISCM Metrics due to the threat that they pose. These generally result from failed or non-credentialed scans.

Software Managed Assets

A Managed Asset that reports at least one (1) application CPE (e.g. java, oracle, Internet Explorer).

The goal is to work towards creating a software asset inventory due to increasing FISMA requirements in software management and configuration.

(16)

3.3 Mission Essential Systems (MES)

An accurate and up-to-date MES List is vital to ensuring the continuity of essential operations in the wake of a calamitous event. The MES List is a federal priority and Components should ensure that all systems deemed mission essential are identified.

Neither non-operational systems nor external information systems may be deemed essential; however, a Component may claim a system as essential that is owned or operated by another Component, provided that system is vital to the first’s mission. Mission essentiality is determined through self-reporting by Components as well as a given system’s Federal

Information Processing Standards (FIPS)-199 Availability rating, which should not be ‘Low’. Those systems qualifying as mission essential are added to a tracking list maintained at the

Enterprise Operations Center (EOC) SharePoint Site.5 The list is reviewed biannually and currently identifies 144 operational systems as mission essential across the enterprise.

3.4 ISO Inventory Reviews

FISMA requires DHS to develop, maintain, and update an inventory of all information systems operated by the Department. The Annual Refresh process is the time period during which ISO helps Components identify any systems missing from the inventory and resolves any other inventory issues.

ISO also assumes authority and responsibility for the unclassified and classified inventory of all Department FISMA systems and assets, enforces change control on that inventory, and assists Components in meeting compliance requirements for proper system categorization and reporting. Scorecard data is assessed for accuracy against official Inventory records for each Component. Any discrepancies identified result in notification to the relevant Component, and the component Inventory is updated pending resolution of the issue.

All procedures and requirements are outlined in the DHS FISMA Inventory Methodology.

3.4.1 FISMA System Inventory Refresh

Components are responsible for maintaining their inventories on an ongoing basis. The Annual Refresh augments this effort by allowing ISO to engage directly with Component personnel to identify any systems missing from the inventory and to recommend inventory updates.

Due to the hundreds of site discovery visits conducted by ISO over the past few years, fewer and fewer systems remain un-inventoried. As a result, discovery visits are now conducted by

Component request, with site recommendations discussed during the Annual Refresh Kickoff meeting.

The typical Refresh lifecycle is described in figure 2. All research, analysis, and conclusions concerning the boundary of a selected system are documented in a formal report submitted by the Annual Refresh deadline of June 30th, 2014.

5

All links within this document will be defined in Appendix K. For access permissions, contact the steward of the site. For SharePoint sites click on the link to request access.

(17)

Figure 2: Inventory Refresh Phases

All critical or time-sensitive changes identified through site visits must be addressed through a change request submitted by the Component or initiated by ISO for Component validation. Components have 45 days to respond, otherwise, the change request goes into effect

automatically.

3.4.2 Inventory Refresh Major Area of Focus

Specific areas of focus are selected each year based on DHS initiatives or Inventory weaknesses. In FY14 the Major Area of Focus for the inventory refresh will be the classification of cloud systems and EISs. The IMT will review all systems categorized as EISs to determine which EISs are cloud systems and whether or not they should be re-categorized. If they are determined to be cloud General Support Systems (GSS) or Major Application then the IMT will take

inventory of all associated applications and systems.

3.4.3 Inventory Management SharePoint Site

The Inventory Management SharePoint Site was established in FY11. It provides Components access to current information and serves as a central, organized location to exchange data. Reference files, such as the Inventory methodology and change request forms, are stored in general access sections. Each Component has a customized page that may only be accessed by members of their organization. With Component CISO approval, the following elements may be stored on the Component’s page:

• Unclassified FISMA system inventory, system leads, and action items • Inventory refresh schedule

• Inventory meeting reports

(18)

4. Information Security Continuous Monitoring

Since 2011, ISCM has become a leading priority at DHS and is one of the three CAP Goals for the Executive Branch in 2014. Continuous Monitoring will help Agencies maintain an up-to-date picture of what assets are on their information networks and when the security statuses of those assets change. ISCM is a Risk Management6 approach that utilizes ongoing awareness of the security posture of information technology assets in order to maintain an accurate picture of organizational risk. This is accomplished through the use of automated security management tools that are able to detect, quantify, report, and potentially mitigate risks on a near real-time basis.

4.1 ISCM Capabilities

NIST SP 800-53 Rev 4 defines security capability as the set of mutually-reinforcing security controls that provides the requisite level of trustworthiness for organizational information systems. Organizations can group

individual controls into capabilities which, when implemented, will mitigate relevant attacks that can have a negative impact to the mission.

In 2012, the White House tasked DHS NPPD with overseeing an Information Security Continuous Monitoring Program on behalf of all Federal and Civilian Departments and Agencies. The

objective of this Program is to obtain CM Tools and Services that will provide federal agencies the ability to enhance and automate their existing continuous monitoring network capabilities, correlate and analyze critical security-related information, and strengthen risk-based decision making at the agency and federal enterprise level.

Figure 3 demonstrates NPPD’s organization of mutually-reinforcing security controls into security capabilities that directly support the ISCM Program.

6_{NIST Special Publication 800-37 r1, Applying the Risk Management Framework to Federal Information Systems.}

(19)

4.2 Federal ISCM Plan and CDM Procurement

The Executive Branch’s CAP Goal for Continuous Monitoring includes transforming the

historically static security control assessment and authorization process into an integral part of a dynamic enterprise-wide risk management process. This change allows departments and

agencies to maintain an ongoing near real-time awareness and assessment of information security risk and rapidly respond to support organizational risk management decisions.

OMB Memorandum M-14-03 (November 18, 2013) provides agencies with guidance for managing information security risk on a continuous basis and builds upon efforts towards achieving the Cybersecurity CAP Goal. Departments will utilize ISCM tools and processes to manage their assets, but will do so in support of FISMA compliance and the NIST 800-37 Risk Management Framework.

In order to support Continuous Monitoring, a Federal Program to help agencies procure CDM tools is underway. The Federal ISCM Program, led by the FNR Branch of NPPD, is sequenced for implementation starting with the “Manage Assets” family of Figure 3 and continuing clockwise.

It is anticipated that the scope of the ISCM program will expand to include the Security Capabilities of Figure 3 in FY15 and beyond. Beginning with the Manage Assets family and proceeding clockwise, it is envisioned that approximately five to six capabilities will become operational each year as shown in Table 2.

Increment 1 Increment 2 Increment 3

Manage Assets

1. Hardware Inventory

2. Software Inventory / Anti-virus 3. Configuration Settings

4. Vulnerabilities

Manage Accounts for People and Services

1. Network/Physical Access Control

2. Trust in People Granted Access 3. Security Related Behavior 4. Credentials & Authentication 5. Account Access

Manage Events

1. Prepare for Incidents and Contingencies 2. Respond to Incidents and Contingencies

Security Lifecycle Management/Design and Build in Security

1. Requirements, Policy and Planning 2. Quality Management

Security Lifecycle Management Operate, Monitor, and Improve

1. Operational Security 2. Generic Audit/ Monitoring

(20)

4.3 DHS’s Approach to ISCM and the CDM Procurement

In FY14, DHS will expand its Information Security Continuous Monitoring Program to achieve greater standardization of ISCM tools. The DHS CIO and CISO will lead a coordinated “One-DHS” deployment of ISCM Capabilities through the Federal CDM Procurement.7 The

consolidated Department-wide approach will: decrease costs and leverage enterprise licensing, facilitate a Common Operating Picture (COP), make funds available for new/complimentary capabilities, and permit cross training and transfer of staff among the Components.

The DHS CIO will work with FNR’s CDM Program to develop an enterprise solution of CDM tools. They will follow a transparent methodology for requirements development and tool selection that will leverage component collaboration. Procurement, implementation, and tool transition will be stewarded by the DHS Office of the Chief Information Security Officer (OCISO) in coordination with the Department’s CIO Council. Procurement activities are

expected to begin in January of 2014 and will continue throughout the remainder of fiscal year. FNR’s CDM program will fully fund costs associated with the transition. OMB has authorized existing budgeted dollars that are not spent to remain at Components for spending on alternate information security efforts (such as the mitigation of vulnerabilities).

4.4 Existing ISCM Capability Groups and Tools

Over the last few years, DHS Components have been at the forefront of implementing

Continuous Monitoring Capabilities. DHS Components have used a variety of tools to meet the technical capabilities required of an effective ISCM Program. DHS has encouraged

standardization by managing ELAs and consolidating numerous disparate contracts and licenses across the Department. By providing access to a common set of ISCM tools, DHS was able to reduce operations and maintenance costs, and expand the availability of the most common capabilities to all DHS Components.

Table 3 outlines the current and future capabilities areas and procurements of the DHS ISCM Program. Current ISCM data collection efforts (section 4.6: Data Collection) are directly aligned with Increment 1 of the Federal CDM Program.

7

“One DHS” Deployment of Continuous Diagnostics and Mitigation (CDM) Capability”, DHS Acting Deputy Secretary Memorandum to Component Heads, November 15, 2013.

(21)

Capability Group Description ELA Tool(s)

Asset

Management Identification of Hardware and Software Assets

Tenable Nessus and/or McAfee ePolicy Orchestrator (ePO)

Network-Based Vulnerability Auditing

Credentialed vulnerability scanning achieved through periodic network scans

Tenable Nessus and Security Center

Configuration management

Agent-based, active detection and remediation of non-compliant configurations. Capable of making changes directly to host endpoints.

TBD

Endpoint Protection

Agent-based solution including capabilities such as anti-virus, anti-malware, host-based Intrusion Detection System (IDS), and removable media protection.

McAfee ePO and Endpoint Protection Advanced tool suite

Table 3: Continuous Monitoring Capability Groups

ISCM documentation supporting these capability areas and tools can be found on the CMWG SharePoint site includes:

• McAfee ePO CM Reference Guide v2.1

• SOP Data Feed Submission version v4.1

• Tenable-Nessus Implementation Guide v2

• Configuration Baseline Audit Files

• Tenable Parser

4.5 ISCM Data

OMB Memo M-14-03 requires agencies to develop an ISCM plan and to deploy Enterprise ISCM products and services instead of multiple disparate services across Agency

Bureaus/Components. While standard enterprise tools are available to all Components, use of these tools will not be mandatory until the Department’s CDM Procurement is complete. Nonetheless, there are monthly reporting standards, and the requirements of these standards are largely based on the capabilities and output formats inherent to the standard enterprise tools. The following chart lists required data elements corresponding to each of the FY14 ISCM metrics. See Appendix A for corresponding metric detail about these capabilities.

(22)

Capability Required Data Elements8

Asset Information

(applies to ALL ISCM metrics)

• FISMA ID • Hostname • CPE Standard • Device Role • Last scan date • Credentialed scan Software Asset Management • CPE (application)

Whitelisting • Accepted CPE (application) according to the Enterprise Architecture (EA) Technical Reference Model (TRM)

Vulnerability Management • CVE standard

• Common Vulnerability Scoring System (CVSS) number

Configuration Management

• Configuration name/version

• Common Configuration Enumeration (CCE) standard • Configuration status (pass, fail, exception)

Anti-Virus

(Endpoint Protection)

• Gathered but not scored:

o Product Version (Host Intrusion Prevention (HIPs)) o Hotfix/Patch Version HIPs

o HIPs Status o Content Version • Scored (Mandatory):

o DAT File Version

o OR Date of Last Definition Update

ISVM

• Gathered but not scored:

o Date of the most recently installed patch o Patch name of the most recently installed patch • Scored (using Vulnerability Management data submitted):

o Verification status of vulnerabilities mitigated from ISVM Alerts and 2 random ISVM Bulletins (1 Workstation Bulletin and 1 Server Bulletin)

Table 4: Data Elements for ISCM Metrics

8

See http://cpe.mitre.org/, http://cve.mitre.org, and http://cce.mitre.org for detailed descriptions of the CPE, CVE, and CCE standards.

(23)

Scan data can be split into different files (e.g. Vulnerability data can be separate from Configuration Management). Each separate file must contain the relevant FISMA ID and Hostname so that the data can be aggregated accordingly. See the SOP Data Feed Submission version v4.1 for template suggestions.

4.5.1 Asset Management

Components are required to identify and report Hardware and Software Assets monthly to the ISO. Properly identifying assets is the single most important way for a Component to improve their score as “Unidentified” assets fail most Continuous Monitoring Metrics. In order to be considered Identified, an asset must pass the following criteria: (1) have a valid FISMA ID, (2) a valid hostname, (3) and an OS CPE. Certain assets (e.g. printers and network devices) that cannot report OS CPE may be classified as “Identified” if their Device Role is properly annotated in their monthly data feeds and match the Universal Device Role List.

4.5.2 Vulnerability Management

Components are required to report vulnerability information for all visible workstations, servers, and virtual machines (where possible). Vulnerabilities are to be reported in SCAP compliant format (i.e. CVE with an associated CVSS score that indicates severity). Only high and critical vulnerabilities will impact the Vulnerability Management metric on the Scorecard, but every asset must report at least one CVE (regardless of CVSS) in order to pass the metric. Each identified asset will be evaluated as to whether it has been scanned and does not exceed the maximum threshold of (100) critical and high vulnerabilities.

4.5.3 Configuration Management

Components must report select configuration baseline data for applicable platforms: • Windows XP (end of life in April 2014)

• Windows 7 • Windows Vista • Windows Server 2003 • Windows Server 2008

• Unix (will be scored starting April 2014) • Linux (will be scored starting April 2014)

• CISCO Router (will be scored starting April 2014)

Additional required platforms, including Windows, UNIX, and Linux servers, will be placed in-scope as ISO tests and publishes applicable baseline audit files. SCAP-compliant CCE data must be provided for each applicable asset, including a pass, fail, or exception status indicating compliance. Configuration settings, found in Appendix I, have been selected from the complete list of USGCB settings to condense the amount of data being submitted. Unidentified assets automatically fail this metric regardless of whether data is provided.

There will be a 2 month grace period, once configuration audit files are published, prior to the platforms being required and scored on the monthly DHS Executive FISMA Scorecard.

(24)

4.5.4 Information Security Vulnerability Management

The ISVM metric focuses on ensuring that DHS SOC ISVM messages are properly addressed across the Department. This metric will verify compliance at the asset level through the vulnerability data submitted to ISO in order to determine that vulnerabilities have been

mitigated. No new, additional reporting is required by Components in order for this metric to be scored. Please note that Component Information System Security Officers (ISSOs) will still continue to respond to ISVM messages and verify compliance in EOC Online.

All Alert ISVMs will be verified and two random Bulletin ISVMs will be verified through this process. There is a 2 month lead time between ISVM messages having been issued and resolved to a relevant patch, and then verified via vulnerability scans.

4.5.5 Endpoint Protection and Antivirus

Components must demonstrate progress in implementing agent-based, endpoint protection measures by reporting whether or not certain capabilities are installed and are active on applicable assets (or hosts). Applicable hosts (workstations and servers) have agents installed and are capable of reporting this information. In FY14, required capabilities are limited to anti-virus (even though host intrusion detection and prevention systems are recommended). Data regarding product versions and updated signature files are also required. A central management platform able to communicate, aggregate, and analyze data from these separate agents or

modules across all hosts is essential to the feasibility of reporting in an efficient and timely manner. The DHS Executive FISMA Scorecard verifies that asset anti-virus definition files have been updated within 30 days of scan-time. Unidentified assets automatically fail this metric.

4.6 Data Collection

Recommended data flow for ISCM metrics begins with data generation and collection at the Component level using automated tools. Tenable Nessus data should be generated in Comma Separated Values (CSV) format or in a way that conforms to the data templates found in the Data Feed SOP (refer to section 4.5: ISCM Data). Other file formats such as Hyper Text Markup Language (HTML), will not be accepted. Once data is consolidated into either a single report or multiple reports corresponding to individual FISMA systems, it should be submitted to the ISO either through the ISCM mailbox ([email protected]) or uploaded to the

CMWG SharePoint Site by the 21st of every month. Submissions will no longer be accepted after the 21st (or the first business day after the 21st) of the month in order to get the DHS Executive FISMA Scorecard delivered on time. Corrections can only be accepted up to two days after the draft DHS Executive FISMA Scorecard is released. All reports are consolidated by the ISO ISCM team for analysis and used in FISMA, CyberScope, and the monthly DHS Executive FISMA Scorecard.

(25)

4.7 ISCM Data Aggregation and Storage

Data is transferred between submission method and the Management Aggregation and Security Tool (MAST), which hosts the CMDB), via encrypted USB flash drives. Access to MAST is physically restricted to all personnel except those supporting continuous monitoring at the ISO. Once data enters MAST, it is not removed for any purpose other than to fulfill mandatory reporting requirements. Data is consolidated and normalized for report generation. It is stored on a standalone, air-gapped system. The import process does not determine or recognize the tool used to provide the data. The application identifies data by field name(s) and required format. This means, any tool can be used to provide ISCM required data as long as all data elements are provided. Components are reminded to submit ISCM data in accordance with the SOP for Data Feed Submissions.

In FY14, the MAST environment will be moved to the Data Center (DC) AppAuth environment in order to reduce processing time and allow ISO to provide feedback and reports at a much faster pace. Updated details and instructions will be provided to the Components prior to the migration. Components will upload ISCM data to a secure file store instead of the traditional method.

5. Security Management

Security management metrics account for established and generally well-understood security practices. Many of these metrics were foundational to the initial development of the information security program at DHS and remain essential to meeting Federal compliance mandates (e.g. FISMA and OMB Circulars). ISO is responsible for the collection, validation, verification, and reporting of this information both internal and external to the Department. ISO provides tools, guidance, and Subject Matter Expertise (SME) to ensure that all Components are able to meet applicable requirements.

With the integration of new technology and best practices such as ISCM, cloud computing, and security control inheritance, the customary ways of addressing these areas of security are gradually transforming. This section describes both the applicable metrics as well as initiatives that are already affecting or will likely affect them in the future. A significant initiative is the desire to reduce the amount of duplicative effort and cost oftentimes necessitated by the Security Authorization process. Security management processes such as common controls, OA, and Security Plan (SP) reduction have been emphasized since FY12 to streamline the SA process for the entire Department. In FY14, OA will take more of a role in transitioning to a better risk management approach.

(26)

5.1 FISMA Compliance Management

DHS uses a compliance workflow and monitoring tool, referred to as Information Assurance Compliance System (IACS), to manage Authorization tasks and other processes. Functions of the tools include:

• The development and monitoring of SA requirements and associated documentation via the NIST SP 800-37 Risk Management Framework (RMF).

• The ability to customize the Requirements Traceability Matrix (RTM) based upon the unique characteristics of the system thus ensuring the ISSO is not overburdened with unnecessary requirements.

• The maintenance of the official inventory of FISMA systems.

• The ability to enter and track POA&Ms and annual security control assessments. IACS provides system owners and ISSOs the ability to develop and continuously monitor SA requirements through the NIST RMF. The ISSO is able to create security plans, contingency plans, along with all of the required documentation as part of the RMF.

The RTM is a document which assists ISSOs and Security Control Assessors (SCAs) with identifying and testing security controls. The proper amount of security controls is critical to provide a confidence in accepting and managing risk for the system—too few controls do not provide the confidence and too many overburden the ISSO with unnecessary controls. IACS provides a mechanism where the ISSO is able to tailor the RTM based upon the system components, environment, and other factors.

IACS is also a component for entering, tracking, and closing POA&Ms, performing annual security assessments; updating system security information, and system security documentation. It provides the ability to track all of this information at the enterprise level making it easier for system owners, ISSOs, component compliance officers, and the ISO to collaborate and report systems’ security posture of the RMF.

ISO performs necessary updates to the tool as a result of changes to either DHS policy or NIST publications (e.g. NIST 800-53 revisions) generally within forty-five (45) days after the change occurs.

5.2 Authorization

The SA process is vital to ensuring that security procedures for all operational DHS systems are properly documented, validated, and updated on a regular basis. The Department currently requires that systems submit updated SA documentation to ISO for review at a minimum of every three years in order to obtain validation of the system’s Authorization package. The ISO performs a comprehensive Document Review (DR) process in order to verify compliance with FISMA, NIST, and DHS requirements and provides a recommendation for initial or continued operation of the system. A detailed explanation of the DR process can be found in Section 5.5: Document Review.

(27)

Components must have a valid Authorization for each applicable system in order to remain compliant with DHS and federal requirements. A valid Authorization is also a requirement of Ongoing Authorization (described in Section 5.4: Ongoing Authorization). To achieve a valid Authorization, the following documents must be completed and validated through the DR process:

• Sensitive But Unclassified system Authorization Package includes:

o Security Plan (must be addressed yearly for CFO-designated Systems) o Security Assessment (SPR) Plan

o Security Assessment Report (SAR)

o Signed Accreditation Decision Letter / ATO o Contingency Plan (CP)

o Contingency Plan Test (CPT) (Yearly) • Classified system Authorization Package includes:

o System Identification Profile (SIP)

o Defense Information Assurance Certification & Accreditation Process (DIACAP) Implementation Plan (DIP)

o Signed Accreditation Decision Letter o Contingency Plan (CP)

A Privacy Threshold Assessment (PTA) was formerly required as part of the Security

Authorization metric but has been incorporated into the Privacy metric (section 5.5.9: Privacy) since FY13.

5.3 Common Controls

A Common Control is an inherited security control or security capability that may be applied to multiple associated systems. Common Controls can be inherited from various sources including GSS, enterprise systems, programs, or other information systems.

As with any locally-applied control, the objective of a common control is to manage and mitigate risk arising from the use of those systems. In FY12, the DHS CISO Council created a High Priority Initiative (HPI 12-I-9) that requires the Department to integrate common controls into the Security Assessment process. To ensure federal compliance, DHS further uses the

aforementioned NIST guidance to help tailor Department common control policies which are maintained in DHS 4300A.

To successfully identify common controls, an organization-wide exercise should take place with the active involvement of Authorization Officials (AO)s and Senior Management. After

identifying the applicable common controls, and AO and/or CISO must accept the risk associated with the DHS Common controls before authorizing and implementing the identified Common Controls.

Greater scrutiny is required as common controls impact more than one system. To effectively implement a common controls program, each associated Component should assign responsibility for common controls to appropriate organization officials (i.e., common control providers) and should coordinate the development, implementation, assessment, authorization and monitoring of common controls across all stakeholders.

(28)

Authorization selection and status reports for common controls should be shared with the appropriate information system owners and AOs. Independent assessments or continuous

monitoring should be used to identify the status of each selected common control. As applicable, the report results should be used to develop a POA&M.

The DHS CISO requires that Components develop one Enterprise Common Control Catalog (CCC), participate in initiatives, and promote integrated guidance. Each Component must also designate a Common Controls Point of Contact (POC) who is responsible for the status of proposed and complete catalogs.

For more information on DHS common control initiatives or how to properly utilize common controls at your organization, refer to the following resources:

• ESSWG SharePoint Portal

• Common Control Catalog Implementation Guide - (Future location) • [email protected] for Common Control Catalog questions/inquires

5.4 Ongoing Authorization

The Department’s three-year accreditation cycle tends to result in an accurate understanding of a system’s security posture only at a given moment in time. Significant shifts in system security may be overlooked during the time period between initial authorization and subsequent reauthorization. To address this concern, the federal government is transitioning to an OA process; a process that enhances time, cost, and labor efficiency by leveraging continuous monitoring, and common controls. An effective OA program enables system-affecting risk determinations based on factors such as control effectiveness or significant system characteristic changes to be made on an ongoing basis.9

DHS, along with the Department of Health and Human Services, is a current co-chair of the interagency OAWG. The group represents a collection of federal agencies working to develop OA pilot programs, best practices, and other general guidance for use across the federal

government. A collaborative website for the OAWG has been created on the OMB Max Portal. OA focuses heavily on Event-Drive Monitoring, which involves evaluating and testing controls when security events or “triggers” occur. Security triggers are to be reported in the Component’s TRigger Accountability Log (TRAL) and provided to ISO on a monthly basis. Upon notification of a trigger, that is deemed severe enough to possibly compromise the security authorization of a system, an Operational Risk Management Board (ORMB), composed of various SMEs, reviews the trigger to determine its impact on security controls and risk to the system. Following ORMB review, the CISO prepares a formal letter to the AO recommending whether or not to maintain the authorization.

9

NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, Appendix F.

(29)

Key concepts of the Ongoing Authorization Program consist of:

• The inclusion of continuous monitoring capabilities, common control catalogs, and adequate resource allocation to system or program level OA eligibility criteria. • Determination of monitoring frequencies for each security control, based on

system-specific characteristics.

• Training and documenting guidance for ISSOs to ensure understanding of new responsibilities.

• The establishment of remediation and escalation processes for control failures and/or incidents.

• Non-compliance thresholds for both suspension of the OA process and requirement for a system to undergo the full SA process.

Although some concepts remain in development, such as how OA will work within the IACS tool, ISO has established the following requirements for entry into the Ongoing Authorization Program:

• Components must have a:

o Robust Continuous Monitoring Program, as measured in the DHS Scorecard with an overall CDM Score of 80% or higher over three (3) consecutive months o Quality Common Control Catalogs

o Designated OA Manager(s) o Chartered ORMB

o Their Authorization and POA&M Metrics Above 80% or higher over three (3) consecutive months

• Each system must have a(n):

o Component Accepted into the OA Program

o An Authorization that will expire no more than 60 days after OA submission o ISSO with collateral responsibilities that are less than 51%

o ISSO trained on OA processes

o Approved CAT and OA Recommendation Letter

ISO maintains a formal OA Methodology which is updated routinely as DHS continues to modify and refine the OA process. Additional details on eligibility requirements and the overall OA program requirements are discussed in the methodology, which can be found on the Ongoing Authorization SharePoint Site.

DHS Components are encouraged to explore methods of engaging in OA at their own

organizations and to communicate strategies, challenges, or questions to the ISO. Please note that Component systems without validated common control catalogs in FY14 may be ineligible for participation in OA.

(30)

Figure 4: Ongoing Auththorization Process

5.5 Document Review

The Authorization process is vital to verifying system security across the Enterprise. Through comprehensive system document reviews, DHS CISO reviewers ensure that Department systems are compliant with FISMA requirements, meet NIST DHS control implementation standards, and are eligible for initial and continued operation. The Department currently adheres to a maximum three-year authorization cycle policy, requiring that systems re-submit system

documentation to ISO every three years to either obtain or maintain a valid Authorization. This review process is called the Document Review process.

The ISO DR Team reviews artifacts submitted as part of the SA package against a minimum set of quality standards as defined in Appendix B of this document. The primary objective is to review documents to ensure completeness and consistency with OMB and FISMA Reporting.

(31)

(32)

The DSH Document Review Methodology is organized into four sections, described in detail in Sections 5.5.1 through 5.5.8, and summarized below:

Figure 6: Document Review Methodology Steps

1. Initiation via the IACS task notification: This section outlines the process for initiating the DR process.

2. Document Review: This section outlines the process(s) for conducting reviews whenever a notification is received.

3. Results: This section details the criteria used by DR Team to issue a decision regarding the Checklist after a package has been reviewed and to tailor future training sessions to continually improve Component document quality.

4. Conference Calls: This section details the management of conference calls that are held to discuss the results after a package has been completely reviewed by the DR Team. Conference calls may also occur before a package review if the Component wishes to discuss requirements or guidance.

(33)

5.5.1 Initiation

To initiate a package review, the system ISSO, Information Security System Manager (ISSM), FISMA Compliance Team & AO will complete Steps One through Five (ATO Decision) of the RMF Process Flow (see Appendix F). Once Step Five (ATO Decision) has received final approval, Xacta will automatically send notification to the CandA Mailbox alerting the DR Team there is a task to approve.

Packages will be reviewed within seven (7) business days with results reflected as the review is completed.

Packages received on or before the 21st of the month (excluding Federal holidays) will be reviewed by end of the month.

5.5.2 Package Categories

Due to the “Work Flow Process” which is the core of the new IACS tool (Appendix F), Xacta, SA Packages can only be reviewed, approved, or disapproved as an entire package unlike previous years where the ISO had implemented a phased approach by establishing “Review Groups.”

The DR Team will review the following documents: • ATO Letter

• Security Plan • Contingency Plan • Contingency Plan Test • Security Assessment Plan • Security Assessment Results • Reliable Traceability Matrix • ISSO Letter

System personnel should upload any supporting documentation, such as relevant policy

documents, SOPs, waivers, exceptions, MOAs, and Service Level Agreements (SLAs) into the “General Information” section within IACS.

5.5.3 Document Review Checklists

A document review checklist is used for both SBU and NSS system reviews to ensure that a standard set of criteria is applied across all package reviews. The checklist correlates to the security requirements of the system and is filtered based on the security categorization of the system in Step One (Categorize Information System).

For each document without a dedicated checklist, a minimum set of criteria is evaluated as follows:

• Consistency – The information stated in the document must be consistent across the entire package.

• Identification – All documents must identify the appropriate system and system-relevant information.

• Complete fields – All relevant and required fields of information must be completed. • Signature – When required, signature from the appropriate authorities are present.

(34)

• Date – Documents must fall within the cycle of authorization in which the system is renewing or initiating.

Each control is assessed against the DHS DR Checklist and results in one of the following: • Pass – The explanation of criteria are fully met.

• Pass with comments – The explanation of criteria are basically met but additional details

are required in order to fully explain system compliance.

• Fail – Criteria are missing, or do not explain system-specific implementation, or provide inaccurate information and remediation/mitigation plans.

5.5.4 Security Plan

Each control response is evaluated for clearness, conciseness, and correctness with regards to four (4) criteria:

Section One of the SP contains information on the system environment, purpose, characteristics, accreditation boundary, and technologies employed within the system. Section One must receive a 100% pass rate in order for the review to continue otherwise it will be sent back to the

Component POC to be updated.

Section Two of the SP is evaluated by randomly selecting one control family from each class of controls (management, operational, and technical). If the initial review of Section One yields a 100% passing rate and Section Two yields a 90% or above passing rate, the entire SP passes. If the passing rate of those three control families is less than 90%, the SP fails and must be sent back to the Component POC for updating.

Once corrections are made and all of the approvals are completed, Xacta will automatically send notification to the CandA Mailbox alerting the DR Team there is a task to approve.

1. What is the solution? The solution can be a device, document, process, or plan. It must be clearly stated as the object that governs the implementation of the security control at hand.

2. How does the solution satisfy the control or requirement? The solution being discussed must be directly correlated to the presented requirements. It must be clear to the reviewer how the system uses the discussed solution to satisfy the requirements set forth by that particular security control.

3. Who is the responsible party for solution management? Although the ISSO may be responsible for the oversight of system security measures, a system-specific role should also be identified as managing, operating, or implementing control-relevant security measures.

4. How frequently is the solution updated or reassessed? Control solutions may be initiated once and continually monitored or they may require continual implementation (as is the case with revisions or updates) or a combination of the two. The timing of the solution implementation should be addressed for each requirement. Please note: a specific time frame must be provided (e.g. quarterly, monthly, every eight weeks); a response of “periodically” is not sufficient.

(35)

Documenting Implemented Controls

Flaw Remediation SI-2

The organization:

a. Identifies, reports, and corrects information system flaws;

b. Tests software updates related to flaw remediation for effectiveness and potential side effects on organizational information systems before

installation; and

c. Incorporates flaw remediation into the organizational configuration management process.

Status:

Implementation:

(a) System X identifies system flaws through monthly scanning of system devices by the SOC using Tenable Nessus and stores the scan reports on a database server that is accessed by the ISSO via the SARGE utility tool. System Flaws are corrected by submitting proposed patches, service packs, hot fixes and updates to the CCB for approval using REMEDY.

(b) System X requires lab testing prior to controlled change release unless immediate risk requires immediate intervention. All impacted sites will be compliant within 90 days of change release.

(c) System X incorporates flaw remediation into the organizational CM process by submitting all patches, service packs, hot fixes and updates to the CCB for approval unless there is an immediate risk requiring immediate intervention. Responsibility:

The ISSO is responsible for reviewing this control at least annually or when there is a change to the Information System.

(36)

Documenting Planned Controls

Media Sanitization MP-6

The organization:

a. Sanitizes information system media, both digital and non-digital, prior to disposal, release out of organizational control, or release for reuse; and b. Employs sanitization mechanisms with strength and integrity

commensurate with the classification or sensitivity of the information.

Status:

Implementation:

(a) System X currently does not have a documented procedure for sanitizing information system media, digital nor non-digital, prior to disposal, release out of organizational control, or release for reuse. System X is currently drafting procedures to address this control and plans to have these procedures approved within 6 months. See POA&M # 25.

(b) System X currently does not have a documented procedure for employing sanitization mechanisms with strength and integrity commensurate with the classification or sensitivity of the information. System X is currently drafting procedures to address this control and plans to have these procedures approved within 6 months. See POA&M # 25.

Responsibility:

The ISSO is responsible for reviewing this control at least annually or when there is a change to the Information System.

When reviewing controls that are planned, the DR Team will review the POA&M(s) listed in IACS to verify the following information:

• The POA&M number in IACS matches the POA&M number listed in the SP. • The POA&M in IACS actually addresses the control the SP claims to address. • The POA&M status in IACS is accurate. It is not uncommon to see POA&Ms in

DHS Information Security Performance Plan

Fiscal Year 2014