Privacy

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.

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.⁹

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.

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.

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.

Figure 5: Document Review Process Flowchart

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.

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 21^st 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.

• 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.

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.

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 IACS marked “Closed,” but the documentation has not been updated in the SP.

Documenting Control Inheritance

Systems that inherit controls from a provider system must document all partially or fully

inherited controls in the appropriate security documentation. References should clearly identify which control line items are either inherited or partially inherited, the CCC title, version number, and date of publication. DO NOT provide implementation details for any control or part of a control that is inherited: DO provide implementation details for any remaining system

responsibility.

The DR Team will review any referenced Common Control to verify inherited and partially inherited controls to ensure all systems’ responsibilities have been addressed.

More information about common controls at DHS may be found in section 5.3.

Physical and Environmental Protection Policy and Procedures PE-1

The organization develops, disseminates, and reviews/updates [Assignment: organization-defined frequency]:

a. A formal, documented physical and environmental protection policy that addresses purpose, scope, roles, responsibilities,

management commitment, coordination among organizational entities, and compliance; and

b. Formal, documented procedures to facilitate the

implementation of the physical and environmental protection policy and associated physical and environmental protection controls.

Status:

Implementation: (a) (b) This control is identified as a common control and is fully inherited from DC1 (Data Center 1 Catalog version 1.1., June 28, 2011).

Responsibility:

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

Configuration Management Settings CM-6 a. Establishes and documents mandatory configuration settings for

information technology products employed within the information system using [Assignment: organization-defined security configuration checklists]

that reflect the most restrictive mode consistent with operational requirements;

b. Implements the configuration settings;

c. Identifies, documents, and approves exceptions from the mandatory configuration settings for

Individual components within the information system based on explicit operational requirements; and

d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.

Status:

Implementation: (a) (c) This control is identified as a common control and is

partially inherited from the DHS CISO Program (DHS CISO Program CCC version 0.3, April 30, 2012).

System Responsibility:

(b) [system-specific configuration settings implementation]

(c) [system-specific identification, documentation, and exception approvals based on operational requirements details]

(d) [system-specific monitoring and configuration changes details]

Responsibility:

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

5.5.5 Results

All Documents Passed

If all documents passed, the DR Team will provide “DHS Document Review” approval and upload the checklist in the “General Information” Section for the System in IACS.

One or More Documents Fail

If one or more documents fail, the DR Team will send notification listing the documents that did not pass and upload the checklist in the “General Information” Section for the System in IACS.

5.5.6 Conference Calls

At the completion of a review, a conference call may be requested to discuss any deficiencies in documentation and to assist the Component with understanding any controls that did not pass.

Conference calls are intended to help improve the long-term quality of the Authorization process and help prevent recurring issues. Reviews will not result in a conference call unless requested by the Component POC

5.5.7 Re-reviews

A document re-review is necessary only if the Component package failed its initial review.

Updated documents are only assessed for those line items that failed the initial review.

Please note that all changes to the new document(s) will be cross-referenced for consistency throughout the package. If changes are inconsistent with other supporting system

documentation, the documents will “Fail.”

5.5.8 Component Auto-Validation

In FY14, Component individuals retain the ability to submit packages that may be validated without always being DR Team reviewed. This process is called auto-validation. For a Component POC to be placed or continue on auto-validation, two criteria must be filled:

• The individual submitting the SA package must be a certified attendee of ISO’s Document Review training (within the past 18 months).

• The reviewer must demonstrate a 90% quality review success rate on all packages submitted the month following certification.

Components must upload the checklist in the “General Information” section for the system and will be reviewed by the DR Team.

Please note that documents may still be randomly inspected by the DR Team, even after the individual is placed on auto-validation. Reviews will be less frequent and chosen at the discretion of the DR Team. Once certified, the ISO Document Review team will concur on Component packages approved by the reviewer within two business days.

ISO suggests that Component personnel performing the full package reviews and checklists prior to CISO Validation be the individual certified through the DR process, as they have a complete

ISO suggests that Component personnel performing the full package reviews and checklists prior to CISO Validation be the individual certified through the DR process, as they have a complete

In document DHS Information Security Performance Plan (Page 27-40)