NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1

Levels of Assessment

• Basic (Contractor Self-Assessment) NIST SP 800-171 DoD Assessment

  • The Basic Assessment is the Contractor’s self-assessment of NIST SP 800-171 implementation status, based on a review of the system security plan(s) associated with covered contractor information system(s), and conducted in accordance with NIST SP 800-171A, “Assessing Security Requirements for Controlled Unclassified Information” and Section 5 and Annex A of this document.

  • The Basic Assessment results in a confidence level of ‘Low’ in the resulting score because it is a self-generated score.

  • iii) The summary level scores resulting from Basic NIST SP 800-171 DoD Assessments should be documented as indicated in Section 6 and Annex B of this document.

• Medium NIST SP 800-171 DoD Assessment

  • i) The Medium Assessment is conducted by DoD personnel who have been trained in accordance with DoD policy and procedures to conduct the assessment. It is anticipated that Medium Assessments will be conducted primarily by Program Management Office cybersecurity personnel, as part of a separately scheduled visit (e.g., for a Critical Design Review).

  • ii) The assessment will consist of a review of the system security plan description of how each requirement is met to identify any descriptions which may not properly address the security requirements.

  • iii) The Medium Assessment results in a confidence level of ‘Medium’ in the resulting score.

  • iv) The DoD assessor will document summary level scores resulting from Medium NIST SP 800-171 DoD Assessments as indicated in Section 6 of this document.

• High (On-Site or Virtual) NIST SP 800-171 DoD Assessment

  • i) The High Assessment, conducted by DoD personnel who have been trained in accordance with DoD policy and procedures to conduct the assessment, requires a thorough on-site or virtual2 verification/examination/demonstration of the Contractor’s system security plan and implementation of the NIST SP 800-171 security requirements.

  • ii) The High Assessment is conducted using NIST SP 800-171A, “Assessing Security Requirements for Controlled Unclassified Information.” The assessment will determine if the implementation meets the requirements by reviewing appropriate evidence and/or demonstration (e.g., recent scanning results, system inventories, configuration baselines, demonstration of multifactor authentication).

  • iii) An on-site High NIST SP 800-171 DoD Assessment is the preferred methodology for a full evaluation of the risk to DoD CUI because of the ability to verify and validate the effectiveness of the safeguards that implement security requirements defined in NIST Special Publication 800-171. While a High Assessment maybe be conducted virtually in lieu of onsite, a virtual assessment will not fully cover all the NIST SP 800-171 requirements, resulting in a less than full understanding of overall risk.

  • iv) A virtual High Assessment utilizes the same methodology as the on-site with added data protections processes enacted to protect the DIB data that is shared with assessment teams. All data is transmitted through DoD Secure Access File Exchange (SAFE), is only reviewed locally on each assessor’s computer (screen sharing is conducted utilizing DoD collaboration mediums that are approved for processing CUI) and contractor data is destroyed post assessment using NSA guidance for data destruction. With concurrence from the DIB companies being assessed, the assessment verifies and examines all documents utilizing the NIST SP 800-171A methodology minus the demonstration or testing of some requirements. In some cases, a follow-up on-site assessment of the items not assessed may be required or requested.

  • v) The first step in a High Assessment is for the contractor to conduct a Basic Assessment and submit results to the Department using the procedures in Annex B of this document. The High Assessment consists of a review of the Basic Assessment, a thorough document review and discussion with the contractor regarding the results to obtain additional information or clarification as needed, combined with government validation that the security requirements have been implemented as described in the system security plan. Network access by the assessor(s) is not required.

  • vi) The High Assessment results in a confidence level of ‘High’ in the resulting score.

  • vii) The DoD assessor will document summary level scores resulting from High NIST SP 800-171 DoD Assessments as indicated in Section 6 of this document.

NIST SP 800-171 DoD Assessment Scoring Methodology

1. This scoring methodology is designed to provide an objective assessment of a
   contractor’s NIST SP 800-171 implementation status. With the exception of
   requirements for which the scoring of partial implementation is built-in (e.g., multi
   factor authentication, security requirement 3.5.3) the methodology is not designed to credit partial implementation.

2. Conduct of the NIST SP 800-171 DoD Assessment will result in a score reflecting the net effect of security requirements not yet implemented. If all security requirements are
   implemented, a contractor is awarded a score of 110, consistent with the total number of NIST SP 800-171 security requirements. For each security requirement not met, the associated value is subtracted from 110. The score of 110 is reduced by each requirement not implemented, which may result in a negative score. 

3. While NIST SP 800-171 does not prioritize security requirements, certain requirements have more impact on the security of the network and its data than others. This scoring
   methodology incorporates this concept by weighting each security requirement based
   on the impact to the information system and the DoD CUI created on or transiting
   through that system, when that requirement is not implemented.

4. Weighted requirements include all of the fundamental NIST SP 800-171 ‘Basic Security Requirements’ -high-level requirements which, if not implemented, render ineffective the more numerous ‘Derived Security Requirements’; and a subset of the ‘Derived Security Requirements’-requirements that supplement the Basic Security Requirements -which, if not implemented, would allow for exploitation of the network and its information.

   • For security requirements that, if not implemented, could lead to significant exploitation of the network, or exfiltration of DoD CUI, 5 points are subtracted
     from the score of 110. For example, failure to limit system access to authorized
     users (Basic Security Requirement 3.1.1) renders all the other Access Control
     requirements ineffective, allowing easy exploitation of the network; failure to
     control the use of removable media on system components (Derived Security
     Requirement 3.8.7) could result in massive exfiltration of CUI and introduction of malware.

     • Basic Security Requirements with a value of 5 points include 3.1.1, 3.1.2,
       3.2.1, 3.2.2, 3.3.1, 3.4.1, 3.4.2, 3.5.1, 3.5.2, 3.6.1, 3.6.2, 3.7.2, 3.8.3, 3.9.2,
       3.10.1, 3.10.2, 3.12.1, 3.12.3, 3.13.1, 3.13.2, 3.14.1, 3.14.2, and 3.14.3.

     • Derived Security Requirements with a value of 5 points include 3.1.12,
       3.1.13, 3.1.16, 3.1.17, 3.1.18, 3.3.5, 3.4.5, 3.4.6, 3.4.7, 3.4.8, 3.5.10, 3.7.5,
       3.8.7, 3.11.2, 3.13.5, 3.13.6, 3.13.15, 3.14.4, and 3.14.6.

   • For Basic and Derived Security Requirements that, if not implemented, have a specific and confined effect on the security of the network and its data, 3 points are subtracted from the score of 110. For example, failure to limit access to CUI on system media to authorized users (Security Requirement 3.8.2) or failure to encrypt CUI stored on a mobile device (Security Requirement 3.1.19), put the CUI stored on the system media or mobile device at risk, but not the CUI stored on the network itself.

     • Basic Security Requirements with a value of 3 points include 3.3.2, 3.7.1,
       3.8.1, 3.8.2, 3.9.1, 3.11.1, and 3.12.2.

     • Derived Security Requirements with a value of 3 points include 3.1.5,
       3.1.19, 3.7.4, 3.8.8, 3.13.8, 3.14.5, and 3.14.7.

   • All remaining Derived Security Requirements, if not implemented, have a limited or indirect effect on the security of the network and its data. For these, 1 point is subtracted from the score of 110. For example, failing to prevent reuse of identifiers for a defined period (Security Requirement 3.5.5) could allow a user access to CUI to which they were not approved.

5. Two Derived Security Requirements can be partially effective even if not completely or properly implemented, and the points deducted should be adjusted depending on how the security requirement is implemented.

   1. Multi-factor authentication (MFA) (Security Requirement 3.5.3) is typically implemented first for remote and privileged users (since these users are both 
      limited in number and more critical) and then for the general user, so 3 points are subtracted from the score of 110 if MFA is implemented only for remote and privileged users; 5 points are subtracted from the score of 110 if MFA is not implemented for any users. 

   2. FIPS validated encryption (Security Requirement 3.13.11) is required to protect the confidentiality of CUI. If encryption is employed, but is not FIPS validated, 3 points are subtracted from the score of 110; if encryption is not employed, 5 points are subtracted from the score of 110. 

6. Although not common, future revisions of NIST SP 800-171 may add, delete or substantively revise security requirements. When this occurs, a value will be assigned to any new or modified requirements in accordance with this scoring methodology.

7. The contractor must have a system security plan (Basic Security Requirement 3.12.4) in place to describe each covered contractor information system, and a plan of action (Basic Security Requirement 3.12.2) in place for each unimplemented security requirement to describe how and when the security requirement will be met.

   1. Since the NIST SP 800-171 DoD Assessment scoring methodology is based on the review of a system security plan describing how the security requirements are met, it is not possible to conduct the assessment if the information is not available. The absence of a system security plan would result in a finding that ‘an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.’

   2. Plans of action addressing unimplemented security requirements are not a substitute for a completed requirement. Security requirements not implemented, whether a plan of action is in place or not, will be assessed as ‘not implemented.’ 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.

   3. A lack of plan of action for unimplemented security requirements will result in Security Requirement 3.12.2 being assessed as ‘not implemented.’  

8. Temporary deficiencies and/or isolated enduring exceptions which occur during initial implementation, or arise after implementation, are to be expected in most complex environments.

   1. Temporary deficiencies that are appropriately addressed in plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities)
      should be assessed as ‘implemented.’ For example, when a plan of action
      addresses a ‘temporary deficiency’ that arises after implementation (e.g.,
      3.13.11, employ FIPS validated cryptography, had been implemented, but
      subsequently a patch invalidated the FIPS validation of a particular cryptographic module), the requirement will be scored ‘as implemented.’ A ‘temporary deficiency’ may also arise during initial implementation of a NIST SP 800-171 requirement if, during roll-out, specific issues with certain equipment is discovered that has to be separately addressed (e.g., certain specific hardware or software unexpectedly needs to be changed for the requirement to be successfully applied). If the implementation roll-out has otherwise been completed, this ‘temporary deficiency’ plan of action would be considered, and the requirement scored ‘as implemented.’ There is no standard duration for which a ‘temporary deficiency’ may be active. It is what is reasonable, which would take into consideration the availability of the solution, the cost and time to implement, the overall risk and whether any mitigations are applied in the interim. Generally, deficiencies should be resolved as soon as is reasonably possible.

   2. Isolated enduring exceptions encountered during implementation, such as
      unique equipment or environments (e.g., specialized manufacturing equipment
      or a unique laboratory environment) may prevent the implementation of certain
      security requirements. Isolated enduring exceptions are typically not suitable to
      address in plans of action, but when described, along with any mitigations, in the system security plan such exceptions should be assessed as ‘implemented.’

9. For certain requirements, questions often arise on whether or not they are actually implemented. These situations are addressed below:

   1. Security Requirements 3.1.12, 3.1.16, 3.1.18: Companies commonly do not
      allow remote access, wireless access or connection of mobile devices and may
      indicate these requirements as ‘Not Applicable’ or ‘Not Implemented’ in the system security plan. The evaluator should not deduct points in such cases. However, if the company disallows use of remote, wireless, or mobile access, they should also have a policy and procedure in place to insure these capabilities are not enabled inadvertently. This should be discussed as part of the Medium Level assessment, and if such policy and procedures are not in place a point should be assessed.

   2. Security Requirement 3.13.8: When implementing this requirement, encryption, though preferred, is not required if using common-carrier provided Multiprotocol Label Switching (MPLS), as the MPLS separation provides sufficient
      protection without encryption.

   3. Security Requirement 3.13.11: Cryptography used to protect the confidentiality
      of CUI must be FIPS-validated, which means the cryptographic module has to
      have been tested and validated to meet FIPS 140-1 or-2 requirements. Simply using an approved algorithm (e.g., FIPS 197 for AES) is not sufficient -the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140. Note however, that this is required when encryption is required for protection, which is typically external to the contractor's covered information system (assuming the system meets NIST SP 800-171). Cryptography used for other purposes within the protected information system need not be FIPS validated. When required, if encryption is not employed (FIPS validated or otherwise), 5 points are subtracted from the score of 110. If encryption is employed, but is not FIPS validated, 3 points are subtracted from the score of 110. Isolated use of non-FIPS validated cryptography, with an associated Plan of Action, should be treated as a temporary deficiency and assessed as ‘implemented.’

10. If a contractor received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective in accordance with DFARS 252.204-7008 or 7012, the DoD CIO assessment should be included in the Contractor’s system security plan. Implemented security measures adjudicated by the DoD CIO as equally effective, and security requirements approved by the DoD CIO as ‘not applicable,’ will be assessed as ‘implemented.’ Once DOD CIO assessments approving “not applicable” requirements or “alternative security measures” are included in the Contractor's system security plan, the contractor does not need to submit that documentation for every current contract with the DFARS 252.204-7012 clause unless specifically requested to do so by the contracting officer. When completing the Basic (Contractor Self-Assessment) NIST SP 800-171 DoD Assessment Results Format, the contractor shall score any security requirements for which an assessment of “not applicable” or “alternative security measures” was previously approved by DoD CIO as ‘implemented’.

11. A template illustrating the application of this scoring methodology is provided at Annex A of this document.

12. DoD will provide medium and high assessment results to the Contractor and offer the opportunity for rebuttal and adjudication of assessment results. Upon completion of each assessment, the assessed contractor has 14 business days to provide additional information to the assessment team, to demonstrate that they meet any security requirements not observed by the assessment team or to rebut the findings that may be of question.