A Complete NIST Guide
NIST SP 800-171 Scoring Methodology
INTRODUCTION
In June 2020, the National Institute of Standards and Technology (NIST) released a Special Publication (SP) supporting the Department of Defense (DoD) supply chain cybersecurity maturity model. NIST SP 800-171 “DoD Assessment Methodology” Version 1.2.1 (Scoring Methodology) offering a way to assess a contractor’s NIST 800-171 implementation strategically. Additionally, as of November 30, 2020, many contractors throughout the Defense Industrial Base (DIB) need to engage in a self-assessment and submit the results to the DoD.
Meanwhile, organizations who are part of the DIB supply chain also need to determine their Cybersecurity Maturity Model Certification (CMMC) level and possible compliance gaps they need to remediate. As the DoD continues to enhance security throughout its supply stream, companies of all sizes need to know their responsibilities and establish strategies for meeting new compliance requirements.
QUESTIONS This article will answer the following questions:
What is the Interim Rule?
On September 20, 2020, the Defense Acquisition Regulations System (DFARS) released “Defense Federal Acquisition Regulation Supplement: Assessing Contractor Implementation of Cybersecurity Requirements (DFARS Case 2019-D041)” (the Interim Rule). The Interim Rule supports the DoD’s decision to standardize cybersecurity practices within the DIB supply chain, noting:
DOD is issuing an interim rule to amend the Defense Federal Acquisition Regulation Supplement (DFARS) to implement a DoD Assessment Methodology and Cybersecurity Maturity Model Certification framework in order to assess contractor implementation of cybersecurity requirements and enhance the protection of unclassified information within the DoD supply chain.
Further, the Interim Rule’s “Background” section explains that the rule implements the NIST SP 800-171 assessment methodology and framework to assess contractor cybersecurity implementation as well as CMMC.
The Interim Rule and NIST 800-171 DoD Assessment Methodology
As part of this implementation, companies need to have a current, defined as less than three years old, NIST SP 800-171 DoD Assessment on record to be considered for a contract award. Companies must complete assessments for each covered contractor information system relevant to the offer, contract, task order, or delivery order. Once completed, contractors upload the assessment to the Supplier Performance Risk System (SPRS).
The contracting officer needs to include the NOtice of NIST SP 800-171 Assessment Requirements in solicitations and contracts unless the solicitations are solely for commercially available off-the-shelf (COTS) items.
The Interim Rule and CMMC Compliance
As part of implementing the Interim Rule, companies managing Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) need to work towards meeting CMMC compliance. The Interim Rule notes, “The NIST SP 800-171 DoD Assessment and CMMC assessments will not duplicate efforts from each assessment, or any other DoD assessment.” This statement implies that organizations needing to certify at CMMC Levels 3 or above can incorporate their Scoring Methodology self-assessment as part of that process.
The Interim Rule also makes contractors responsible for “information flow down to its subcontractors in a multi-tier supply chain.” This statement places the governance burden on contractors who need to ensure that their subcontractors obtain and maintain the appropriate CMMC Level certification.
Finally, the Interim Rule adds a new DFARS subpart, Subpart 204.75 that directs contracting officers to verify offerors’ and contractors’ CMMC certification in SPRS.
What is the NIST SP 800-171 DoD Assessment Methodology?
The Scoring Methodology document outlines why the DoD requires assessments and how the scoring works.
Strategic Assessment of Contractor Implementation
The DoD plans to use the Assessments for current and future contracts that include DFARS Clause 252.204-7012, “Safeguarding Covered Defense Information and Cyber Incident Reporting.” With the Scoring Methodology, NIST seeks to establish standard metrics for assessing contractors’ implementation of SP 800-171 and not to add any additional requirements. The DoD will apply this Scoring Methodology to its prime contractors and strongly suggests that Primes can use it to assess their subcontractors.
Levels of Assessment
As part of the strategic approach to managing DIB supply chain risk, the DoD established three assessment levels based on review depth and confidence level to streamline audits and reviews.
Basic (Contractor Self-Assessment)
Using the system security plans associated with covered contractor information systems, organizations need to engage in self-assessments documenting their current implementation. The summary level scores need to be documented and uploaded to the DoD system. However, these scores have a “Low” confidence because they are self-generated and lack DoD verification.
Medium
DoD personnel, primarily Program Management Office (PMO) cybersecurity personnel, trained in the appropriate policies and procedures conduct Medium Assessments. The DoD personnel review the system security plan requirement descriptions to ensure they adequately address the security requirements. Because Medium Assessments do not incorporate documentation, they provide a Medium confidence level.
High (On-Site or Virtual)
Although On-Site High Assessments are the preferred method, the DoD recognizes the health risks related to the continuing COVID-19 pandemic, which is why it also offers a virtual option. Trained DoD personnel conduct High Assessments, requiring contractors to provide evidence or demonstration of their system security plan and its implementation. Examples of evidence include:
- Recent scanning results
- System inventories
- Configuration baselines
- Demonstration of multifactor authentication
However, contractors need to submit a Basic Assessment first. The High Assessment is primarily an audit check consisting of document review and discussion to validate the Basic Assessment responses.
How does the NIST SP 800-171 Scoring Methodology Work?
Under NIST’s Scoring Methodology, organizations need to achieve a score of 110 points out of a possible 110 points. However, instead of building from zero and giving points for each necessary control, NIST subtracts points from 110 for each control that an organization lacks.
Types of Security Requirements
NIST 800-171 Scoring Methodology references NIST SP 800-171 to define security requirement types.
NIST SP 800-171 notes that protecting CUI means establishing Basic Security Requirements as outlined in the Federal Information Protection Standard (FIPS) Publication 200. The controls considered Basic Security Requirements are the same as the minimum security requirements listed in FIPS 200. NIST SP 800-171 notes that these requirements provide “the high-level and fundamental security requirements for federal information and systems.”
Derived Security Requirements supplement the Basic Security Requirements and come from security controls listed in NIST SP 800-53. NIST 800-53 notes:
derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements
associated with such capabilities, functions, and mechanisms include degree of correctness, completeness,
resistance to tampering or bypass, and resistance to direct attack.
Derived Security Requirements act as controls that support the effectiveness of the Basic Security Requirements.
Implementation Status
In keeping with the Cybersecurity Maturity Model Certification (CMMC) process, the Scoring Methodology is not a risk assessment but establishes an implementation status assessment. In other words, the NIST Scoring Methodology calculates the completeness of a contractor’s NIST 800-171 implementation. Additionally, the Scoring Methodology only counts partial implementation in a few cases. Thus, organizations need to completely implement all 110 security controls to achieve a score of 110.
Since organizations need to implement all 110 security controls, the Scoring Methodology subtracts points for unimplemented controls rather than awarding points per control implemented.For example, all organizations start with a score of 110. Assume that a company lacks a control valued at 1 point. The Scoring Methodology detracts that point from 110, assigning the company a score of 109.
Weighted Values
NIST explains that it does not prioritize any of the security controls listed but does believe some controls have a more significant impact than others. As such, NIST established a “weighted” value for each security requirement.
5 Point Security Requirements
“Basic Security Requirements” have a value of 5 points. These requirements are considered high-level requirements that, if not implemented, can render their “Derived Security Requirements” ineffective. Additionally, a subset of “Derived Security Requirements” also has a value of 5 points because the Basic Security Requirement they support needs them to prevent a cybercriminal from undermining them.
23 Basic Security Requirements have a 5 point value:
3.1.1
Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
3.1.2
Limit system access to the types of transactions and functions that authorized users are permitted to execute.
3.2.1
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
3.2.2
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
3.3.1
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
3.4.1
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
3.4.2
Establish and enforce security configuration settings for information technology products employed in organizational systems.
3.5.1
Identify system users, processes acting on behalf of users, and devices.
3.5.2
Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
3.6.1
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
3.6.2
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
3.7.2
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
3.8.3
Sanitize or destroy system media containing CUI before disposal or release for reuse.
3.9.2
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
3.10.1
Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals.
3.10.2
Protect and monitor the physical facility and support infrastructure for organizational systems.
3.12.1
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
3.12.3
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls
3.13.1
Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.
3.13.2
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
3.14.1
Identify, report, and correct system flaws in a timely manner.
3.14.2
Provide protection from malicious code at designated locations within organizational systems.
3.14.3
Monitor system security alerts and advisories and take action in response.
18 Derived Security Requirements have a 5 point value:
3.1.12
Monitor and control remote access sessions.
3.1.13
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
3.1.16
Authorize wireless access prior to allowing such connections.
3.1.17
Protect wireless access using authentication and encryption.
3.1.18
Control connection of mobile devices.
3.3.5
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
3.4.5
Establish and enforce security configuration settings for information technology products employed in organizational systems.
3.4.6
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
3.4.7
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
3.4.8
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
3.5.10
Store and transmit only cryptographically-protected passwords.
3.7.5
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
3.8.7
Control the use of removable media on system components.
3.11.2
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
3.13.5
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
3.13.6
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
3.13.15
Protect the authenticity of communications sessions.
3.14.4
Update malicious code protection mechanisms when new releases are available.
3.14.6
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
5 Point Security Requirements
NIST notes that some Basic and Derived Security Requirements have a specific and confined effect on network and data security if not implemented. Although their impact is not as significant as the Requirements valued at 5 points, they have a more substantial impact than other general Requirements. Thus, NIST values these as 3 points each.
7 Basic Security Requirements have a 3 point value:
3.3.2
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
3.7.1
Perform maintenance on organizational systems.
3.8.1
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
3.8.2
Limit access to CUI on system media to authorized users.
3.9.1
Screen individuals prior to authorizing access to organizational systems containing CUI.
3.11.1
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
3.12.2
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
7 Derived Security Requirements have a 3 point value:
3.1.5
Employ the principle of least privilege, including for specific security functions and privileged accounts.
3.1.19
Encrypt CUI on mobile devices and mobile computing platforms.
3.7.4
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
3.8.8
Prohibit the use of portable storage devices when such devices have no identifiable owner.
3.13.8
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
3.14.5
Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.
3.14.7
Identify unauthorized use of organizational systems.
1 Point Security Requirements
NIST considers the remaining 56 Derived Security Requirements to have a limited or indirect effect on network and data security. Thus, the Scoring Methodology values these as 1 point each.
Noted Exceptions
The Scoring Methodology explains that two of the Derived Security Requirements may be partially effective even if not entirely or correctly implemented. These requirements are the only two with variable point values.
Multi-Factor Authentication (MFA)
MFA needs to be implemented across in two stages for three different use cases. The first step is to require MFA for remote users and privileged users. The second step is to enable MFA for the general user.
If MFA is enabled only for remote and privileged users, the Scoring Methodology subtracts 3 points from the total score.
If no MFA is enabled, the Scoring Methodology subtracts 5 points from the total score.
FIPS Validated Encryption
If the organization employs encryption but not FIPS validated encryption, the Scoring Methodology subtracts 3 points.
If no encryption is employed, the Scoring Methodology subtracts 5 points.
How Is a System Security Plan Used?
All assessments start with a contractor’s system security plan (SSP). NIST 800-18 defines an SSP as the:
Formal document that provides an overview of the security requirements for the information system and describes the security
controls in place or planned for meeting those requirements.
Since NIST notes that SSPs are “living documents,” organizations must periodically review and modify them. Additionally, they need to address plans of action and milestones for implementing security controls.
Although NIST SP 800-18 focuses on agencies, its inclusion in FIPS 200 makes it applicable to contractors managing CUI.
What should be in an SSP?
Since all 800-171 assessments start with an SSP, understanding what needs to be in the document is the first step to moving through the assessment process.
Page 28 of NIST 800-18 sets out a sample template for establishing an SSP. The template incorporates:
- Information System Name/Title
- Information System Categorization (Low/Medium/High)
- Information System Owner
- Authorizing Official
- Other Designated Contacts
- Assignment of Security Responsibility
- Information System Operational Status (Operational/Under Development/Major Modification)
- Information System Type (Major Application/General Support System)
- General Description/Purpose
- System Environment (hardware, software, and communications equipment)
- System Interconnections/Information Sharing
- Related Laws/Regulations/Policies
- Minimum Security Controls
- Information System Security Plan Completion Date
- Information System Security Plan Approval Date
When completing the Minimum Security Controls section of the SSP, organizations need to include:
- Baseline of low-, moderate-, or high-impact
- Security control title
- How the security control is implemented or planned to be implemented
- Scoping guidance applied and type of consideration
- Whether security control is common control and responsible party for implementation
For organizations that need to engage in an Assessment, the security control implementation or planned implementation is one of the most critical aspects of the SSP. The SSP needs to show that all 110 security controls are implemented. For the security controls not yet implemented, the SSP needs to describe the plan of actions and proposed timeline.
Plans of Action
For every unimplemented security control, a company must supply a plan of action. Under the Scoring Methodology, the plan of action is not a replacement for a completed requirement. Security controls listed in a plan of action, even those that are partially implemented, will be assessed as “not implemented.” NIST explains:
For example, if the initial roll-out of 3.5.3, multifactor authentication, is only 75% complete, and there is a plan of action still being
implemented, 3.5.3 will be considered ‘not implemented,’ as the requirement has not been fully implemented.
In short, the NIST Scoring Methodology applies an “all or nothing” approach with no “partial credit” for good intentions.
Temporary Deficiencies
NIST expects that in complex environments, an initial implementation may have a deficiency or isolated exception. Unlike unimplemented controls, the temporary deficiencies are implemented controls that do not work as intended. Although NIST does not define a timeline for fixing temporary deficiencies, it notes that the company should complete remediation “as soon as is reasonably possible.”
NIST notes that these should be considered “implemented” but that the organization needs to establish a plan of action that addresses the “temporary deficiency.” NIST provides the example of FIP validated encryption that subsequently requires a patch that the organization fails to apply, invalidating the encryption. This type of issue will be scored as “implemented.”
NIST also supplies the example of an implementation that relies on equipment that needs to be changed before the implementation is successful. This will also be scored as “implemented” under the “temporary deficiency” category and requires the organization to establish a “plan of action” to fix the problem.
Enduring Exceptions
In some cases, problems may occur during implementation and can be considered “enduring exceptions” that prevent an organization from implementing certain security requirements. NIST expects that these exceptions will be isolated, applying to unique equipment or environments such as specialized manufacturing equipment or laboratory environments.
A plan of action is not likely to fix the problem, but the organization should document mitigating controls that allow the DoD to assess the exception as “implemented.”
How to Report Basic (Contractor Self-Assessment) NIST SP 800-171 DoD Assessment Results?
All organizations handling CUI need to document their Basic Self-Assessment and submit their score to the DoD in the Supplier Performance Risk System (SPRS). Each contractor needs to include the following when reporting their results:
- Assessment date
- Summary level score based on 110 points
- Basic assessment scope
- Plan of action completion date
Basic Assessment Scope
When reporting the scope, organizations need to identify each SSP that will support contract fulfillment and map all Commercial and Government Entity (CAGE) Codes to the appropriate SSP.
Companies with more than one SSP may need to include a brief description of the plan architecture.
Plan of Action Completion Date
Organizations need to submit proposed completion dates for each SSP that does not achieve a score of 110. The completion date is the target date by which all plan(s) of action will be completed.
