ML22077A405
| ML22077A405 | |
| Person / Time | |
|---|---|
| Issue date: | 01/01/2018 |
| From: | Jonathan Feibus NRC/OCIO |
| To: | |
| Shared Package | |
| ML22077A369 | List: |
| References | |
| CSO-PROS-1324 | |
| Download: ML22077A405 (8) | |
Text
Nuclear Regulatory Commission Computer Security Organization Office of the Chief Information Officer Computer Security Process Office Instruction:
CSO-PROS-1324 Office Instruction
Title:
U.S. Nuclear Regulatory Commission Deviation Request Process Revision Number:
2.4 Effective Date:
January 1, 2018 Primary Contacts:
Bill Dabbs Responsible Organization:
OCIO/CSO Summary of Changes:
CSO-PROS-1324, Deviation Requests, describes the process for NRC to identify security weaknesses that qualify for deviation requests and the process for submitting a deviation request.
Training:
As requested ADAMS Accession No.:
ML12083A142 Officer Owner Primary Office of the Chief Information Officer (OCIO)
Computer Security Organization (CSO)
CSO-PROS-2016 i
TABLE OF CONTENTS 1
PURPOSE............................................................................................................................................. 1 2
GENERAL REQUIREMENTS............................................................................................................... 1 3
DEVIATION REQUEST PROCESS..................................................................................................... 2 3.1 COMPLETING THE DEVIATION REQUEST FORM.................................................................................. 3 4
DEVIATION APPROVAL PROCESS................................................................................................... 4 4.1 SECURITY DOCUMENTATION UPDATES............................................................................................. 5 4.2 PERIODIC REVIEW........................................................................................................................... 5
CSO-PROS-1324 1
Computer Security Process CSO-PROS-1324 Deviation Request Process 1 PURPOSE CSO-PROS-1324, U.S. Nuclear Regulatory Commission (NRC) Deviation Request Process describes the process to request a deviation in order to allow the operations or continued operations of NRC systems, including NRC Safeguards Information (SGI) systems, that do not comply with the recommended security control requirement(s) and guidelines as outlined in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 (as Amended), Recommended Security Controls for Federal Information Systems and Organizations.
A Deviation Request (DR) is a formal request to the Authorizing Official (AO) to accept the risk of a weakness that will not be mitigated.
The information contained in this document is intended to be used by system owners, information system security officers (ISSOs), approved security personnel, technical system support staff, the Computer Security Organization (CSO), and the AO.
2 GENERAL REQUIREMENTS The Federal Information Security Modernization Act (FISMA) of 2014 requires each agency to develop, document, and implement an agency-wide program to provide information security. In general, security must be planned, security responsibilities must be assigned and risk factors must be minimized. The current status of the security program and the planned or in-place security controls must be understood to make informed judgments and investments that appropriately mitigate risk to an acceptable level.
In accordance with FISMA, NIST developed an integrated Risk Management Framework (RMF) to provide guidance to effectively and efficiently manage risks of information technology (IT) systems. This risk-based approach is a structured six step process designed to integrate information security and risk management activities into the system development life cycle (SDLC). It provides guidelines that address security categorization, security control selection and implementation, security control assessment, information system authorization and security control monitoring. The ultimate objective is to conduct day-to-day operations and accomplish the agency missions with security that is commensurate with risk, in terms of the magnitude of harm resulting from the unauthorized access, use, disclosure, disruption, modification, or destruction of information. The Deviation Request process outlined herein is aligned with the NIST RMF. Typically, Deviation Requests are addressed during the Assess Security Controls and Authorize Information Systems steps of the RMF.
CSO-PROS-1324 2
Below are some examples of driving factors for deviation requests:
Technical System Limitations Implementation of some controls, in certain situations, may have a negative impact on system operations. For instance, implementation of a required operating system (OS) configuration setting may disrupt or disable NRC custom software or an NRC legacy application. It may be determined that the risk of unavailability of an application (i.e. application will break if the setting is implemented) exceeds the risk of a security event resulting from non-implementation.
Business Process Impact There may be isolated situations where implementation of security controls would severely impact normal business processes. For instance, some systems in emergency response environments, may be accessed infrequently but timely system access is critical when required.
In this particular situation, the system owner may decide to submit a Deviation Request for the requirement to automatically disable accounts after 35 days of inactivity.
Cost-Risk Analysis Security should always be commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information. In some cases, organizations may determine that the cost associated with mitigating the weakness would exceed the adverse impact of a security event. For instance, automated mechanisms to support the management of system accounts [AC-2 (E1)] are required for all Moderate and High impact systems. It may be determined that the cost to implement automated mechanisms exceeds the risk of a potential adverse impact, assuming the system has a very limited number of system accounts and existing manual processes are timely and effective.
Please note-federally mandated requirements cannot be deviated however the authorizing official can accept the risk of having that deficiency in an NRC information system until the resources or technology to fix the deficiency are available.
Examples include the following, but others may apply:
Federal Information Processing Standards (FIPS) are standards for federal computer systems that are developed by National Institute of Standards and Technology (NIST) in accordance with the Federal Information Security Management Act (FISMA) and approved by the Secretary of Commerce.
Homeland Security Presidential Directive-12 (HSPD 12) issued in 2004 is the directive that calls for all federal employees and contractors to use a standard smart credential to verify their identity for secure access to federal buildings and information systems.
Trusted Internet Connection Initiative (also known as TIC) was issued by Office of Management and Budget (OMB) Memorandum M-08-05) back in November 2007. The overall purpose of the TIC initiative was to optimize and standardize individual external network connections currently in use by the federal government.
3 Deviation Request Process Initially, newly identified weaknesses must be added to the systems Plan of Action and Milestones (POA&M) within the period specified in the NRC POA&M process, CSO-PROS-
CSO-PROS-1324 3
2016. Each weakness must be analyzed, and corrective actions documented. If, after the analysis, the system owner concludes that a particular weakness cannot or will not be mitigated and the weakness presents an acceptable risk to the organization, the system owner or designee must create the deviation request using the Deviation Request Form (Excel spreadsheet. The Deviation Request Form itemizes and details the reason and rationale for the request and is used to itemize and track the request. The system owner or designee may want to meet with the technical team to ensure that descriptions of compensating controls or countermeasures are provided for each weakness listed in the deviation request. A compensating control is an alternative mechanism that is put in place to satisfy the requirement for a security measure that is deemed too difficult or impractical to implement at the present time.
The Deviation Request Form is submitted by the system owner or designee through NRC email to their applicable CSO Point of Contact (POC) requesting that a formal review/analysis take place to receive official agency approval. The CSO POC will ensure an NRC-approved independent assessor can analyze the Deviation Request Form and create the Deviation Request Analysis Report (DRAR).
After thorough research and analysis, the DRAR is submitted to the system owner or designee for review as a draft. If the system owner or designee has questions or comments, they can contact and/or meet with the NRC-approved independent assessor, ISSO, and/or the CSO POC and have the opportunity to make edit/updates to the Deviation Request Form. The DRAR must be approved by the ISSO and the CSO POC before the DRAR can be finalized.
Once the DRAR is finalized, submitted, and approved by the CSO POC, the NRC-approved independent assessor creates the final package which gets delivered to the CSO POC with a carbon copy (cc) to the ISSO. The final package includes the following:
Deviation Request Form Deviation Request Analysis Report (DRAR)
The CSO POC will conduct final review of the package and forward along to the CISO for official delivery/review ensuring that appropriate POCs are ccd on the email. The CISO or Deputy CISO can authorize a moderate risk deviation, but a high risk must be approved by the AO.
3.1 Completing the Deviation Request Form The Deviation Request Form description table describes the content for each of the prescribed fields found in the deviation request form spreadsheet.
Data Element Description Deviation Item ID#
Unique ID# for each entry created in sequential order. The format for this is YY-XX (e.g., 22-01). The YY represents the fiscal year.
CSO-PROS-1324 4
Data Element Description Cybersecurity Requirement Enter the NIST identifier (NIST SP 800-53 security control, Defense Information Systems Agency (DISA) Vulnerability ID, Nessus ID, etc.) and description of the requirement for which a deviation is being requested.
Examples:
AC-2 (E1): The organization employs automated mechanisms to support the management of information system accounts.
CM-6, DISA-V-5626 The switch must be configured to use 802.1x authentication on hosts facing access switch ports.
Requested Deviation State the specific deviation requested.
Examples:
Waive the automated mechanism requirement to support the management of system accounts.
Waive the requirement to use 802.1x authentication on hosts facing access switch ports.
Device Name (s)
Function or software affected List the device(s) and/or operating system that would be affected by the request.
Examples:
XYZ system Windows servers Cisco switches Source of Weakness Enter the title of the source/document that identified the weakness or finding.
Include the date and ML#.
Examples:
Periodic Cybersecurity System Assessment (PCSA) Report FY17 Q3 Findings Tracking Sheet OIG Audit Scan Report POA&M ID Enter the POA&M IDs associated with this weakness.
Security Risk per original source Enter the risk level/severity level assessed from the original source/document where the weakness was discovered.
Overall Impact Explain why the requirement cannot be met including the potential impact if a compromise to the confidentiality, integrity, or availability of the data occurred.
Notate the impact level as low, moderate, or high. Define the risk-reducing compensating controls/countermeasures that are in place to reduce the risk.
It is critical for the system owner or designee to carefully consider the current threat environment and the inherent risk of the weaknesses. The justification and compensating controls must clearly support a position that unmitigated weaknesses do not present unacceptable risks to the NRCs mission/business objectives.
4 Deviation Approval Process For high risk deviation requests, the AO considers the CSO review (DRAR), the CISOs recommendation, and weighs the risk against the mission need before making a final decision to approve or deny the request. If the AO determines the risk(s) to be acceptable, an email will be
CSO-PROS-1324 5
sent to the system owner approving the requested deviations and placed into ADAMS by the ISSO.
If the AO determines the risk(s) to be unacceptable, an email will be sent to the system owner denying the request for the deviation and will direct that related weaknesses be added to the list of POA&Ms and processed accordingly. The ISSO is responsible for placing the denial email into ADAMS.
4.1 Security Documentation Updates The system owner or designee is responsible for updating system security documentation consistent with the AOs decision. If the request is approved, the email should be placed into ADAMS and the ML number used to close the related weakness in the systems POA&M.
Corresponding updates should be made to the System Security Plan (SSP) and the control status in the SSP should reflect Risk Based Decision. A brief description of the unsatisfied portion of the control along with the ADAMS ML number of the approval email should be noted in the security control implementation details. If the request is denied, update the systems POA&M and manage the weakness per NRC POA&M guidance.
4.2 Periodic Review Approved deviations do not expire but must be reviewed during the systems Periodic System Cybersecurity Assessments (PSCAs) for validity. Potentially, the risk may have been mitigated through some other event such as implementation of a newly released patch, implementation of an alternate processing site, hardware that has been retired / replaced, or a vendor upgrade to an application that directly satisfies a control. Risk tolerance levels within an organization may change. Risks that were once acceptable may now be unacceptable due to advanced threats or newly identified attacks. Conversely, risk acceptance may increase in the event of reduced funding. The periodic review must determine whether compensating security measures are consistent with the current threat environment.
CSO-PROS-1324 6
CSO-PROS-1324 Change History Date Version Description of Changes Method Used to Announce & Distribute Training 05-Oct-17 2.0 Revised Process OCIO/CSO website As needed 09-Feb-18 2.1 Administrative Changes OCIO/CSO website As needed 08-Jan-19 2.2 Moderate risk DRs can be approved by the CISO or Deputy CISO OCIO/CSO website As needed 18-Aug-20 2.3 Added language about federally mandated requirements in Section
- 2.
OCIO/CSO website As needed 10-June-21 Annual review no updates needed therefore a version number change was not necessary.
OCIO/CSO website As needed 23-Feb-22 2.4 Annual review-Minor edit to Data Element field from deviation request ID# to deviation item ID#
OCIO/CSO website As needed