DoD Assessment Methodology: Difference between revisions
No edit summary |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you. | For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you. | ||
= DoD Assessment Scoring Methodology = | == DoD Assessment Scoring Methodology == | ||
[a] This scoring methodology is designed to provide an objective assessment of a contractor’s NIST SP 800-171/CMMC L2 Practice implementation status. Except for the practice for which the scoring of partial implementation is built-in (e.g., FIPS validated encryption, security requirement 3.13.11/CMMC Practice SC.L2-3.13.11) the methodology is not designed to credit partial implementation. However, partial credit can be applied for Derived Security Requirements that fall under practice SC.L2-3.13.11 - FIPS validated encryption, see paragraph “h” for additional guidance on partial credit for this practice based on how the practice is implemented. | [a] This scoring methodology is designed to provide an objective assessment of a contractor’s NIST SP 800-171/CMMC L2 Practice implementation status. Except for the practice for which the scoring of partial implementation is built-in (e.g., FIPS validated encryption, security requirement 3.13.11/CMMC Practice SC.L2-3.13.11) the methodology is not designed to credit partial implementation. However, partial credit can be applied for Derived Security Requirements that fall under practice SC.L2-3.13.11 - FIPS validated encryption, see paragraph “h” for additional guidance on partial credit for this practice based on how the practice is implemented. | ||
Line 14: | Line 14: | ||
[e] 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/CMMC Practice AC.L1-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/CMMC Practice MP.L2-3.8.7) could result in massive exfiltration of CUI and introduction of malware. | [e] 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/CMMC Practice AC.L1-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/CMMC Practice MP.L2-3.8.7) could result in massive exfiltration of CUI and introduction of malware. | ||
:i. Basic Security Requirements/CMMC Practices with a value of 5 points include AC.L1-3.1.1, AC.L1-3.1.2, AT.L2-3.2.1, AT.L2-3.2.2, AU.L2-3.3.1, CM.L2-3.4.1, CM.L2-3.4.2, IA.L1-3.5.1, IA.L1-3.5.2, IR.L2-3.6.1, IR.L2-3.6.2, MA.L2-3.7.2, MP.L1-3.8.3, PS.L2-3.9.2, PE.L1-3.10.1, PE.L2-3.10.2, CA.L2-3.12.1, CA.L2-3.12.3, SC.L1-3.13.1, SC.L2-3.13.2, SI.L1-3.14.1, SI.L1-3.14.2, and SI.L2-3.14.3. | :i. Basic Security Requirements/CMMC Practices with a value of 5 points include AC.L1-3.1.1, AC.L1-3.1.2, AT.L2-3.2.1, AT.L2-3.2.2, AU.L2-3.3.1, CM.L2-3.4.1, CM.L2-3.4.2, IA.L1-3.5.1, IA.L1-3.5.2, IR.L2-3.6.1, IR.L2-3.6.2, MA.L2-3.7.2, MP.L1-3.8.3, PS.L2-3.9.2, PE.L1-3.10.1, PE.L2-3.10.2, CA.L2-3.12.1, CA.L2-3.12.3, SC.L1-3.13.1, SC.L2-3.13.2, SI.L1-3.14.1, SI.L1-3.14.2, and SI.L2-3.14.3. | ||
:ii. Derived Security Requirements with a value of 5 points include AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.16, AC.L2-3.1.17, AC.L2-3.1.18, AU.L2-3.3.5, CM.L2-3.4.5, CM.L2-3.4.6, CM.L2-3.4.7, CM.L2-3.4.8, IA.L2-3.5.3, IA.L2-3.5.10, MA.L2-3.7.5, MP.L2-3.8.7, RA.L2-3.11.2, SC.L1-3.13.5, SC.L2-3.13.6, SC.L2-3.13.15, SI.L1-3.14.4, and SI.L2-3.14.6. | :ii. Derived Security Requirements with a value of 5 points include AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.16, AC.L2-3.1.17, AC.L2-3.1.18, AU.L2-3.3.5, CM.L2-3.4.5, CM.L2-3.4.6, CM.L2-3.4.7, CM.L2-3.4.8, IA.L2-3.5.3, IA.L2-3.5.10, MA.L2-3.7.5, MP.L2-3.8.7, RA.L2-3.11.2, SC.L1-3.13.5, SC.L2-3.13.6, SC.L2-3.13.15, SI.L1-3.14.4, and SI.L2-3.14.6. | ||
[f] For Basic and ‘Derived Security Requirements’ that, if not implemented, have a specific and | [f] 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/ CMMC Practice MP.L2-3.8.2) or failure to encrypt CUI stored on a mobile device (Security Requirement 3.1.19/CMMC Practice AC.L2-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. | ||
:i. Basic Security Requirements with a value of 3 points include AU.L2-3.3.2, MA.L2-3.7.1, MP.L2-3.8.1, MP.L2-3.8.2, PS.L2-3.9.1, RA.L2-3.11.1, and CA.L2-3.12.2. | |||
:ii. ‘Derived Security Requirements’ with a value of 3 points include AC.L2-3.1.5, AC.L2-3.1.19, MA.L2-3.7.4, MP.L2-3.8.8, SC.L2-3.13.8, SI.L1-3.14.5, and SI.L1-3.14.7. | |||
[g] 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. | |||
[h] ‘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/practice is implemented. | |||
:i. FIPS validated encryption (CMMC Practice SC.L2-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. | |||
[i] Although not common, future revisions of NIST SP 800-171 and/or the CMMC Assessment Guide may add, delete, or substantively revise security requirements and CMMC Practices. When this occurs, a value will be assigned to any new or modified requirements in accordance with this scoring methodology. | |||
[j] The contractor must have a system security plan (CMMC Practice CA.L2-3.12.4 ) in place to describe each covered contractor information system, and a plan of action (Practice CA.L2-3.12.2) in place for each unimplemented security requirement to describe how and when the security requirement will be met, not to exceed 180 days from the Assessment Final Recommended Findings Briefing (Phase 3). | |||
:(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 SC.L2-3.13.11, FIPS validated encryption , is only 75% complete due to vendor issues, and there is a plan of action still being implemented, SC.L2-3.13.11 will be considered ‘not implemented’, as the requirement has not been fully implemented. | |||
:(3) A lack of plan of action for unimplemented practices will result in CMMC Practice CA.L2-3.12.2 being assessed as ‘Not Met.’ During Phase 2 of the assessment process the OSC will populate CMMC Practice deficiencies on a POA&M to fulfill the objective level requirements for CMMC Practice CA.L2-3.12.2. Failure to generate an updated or complete POA&M document for the CMMC L2 assessment will result in CMMC practice CA.L2-3.12.2 being scored “NOT MET” and the CMMC L2 Interim Assessment Certification “Not Achieved.” | |||
[k] Temporary deficiencies and/or isolated enduring exceptions which occur during initial implementation, or arise after implementation, are to be expected in most complex environments. | |||
[l] 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., SC.L2-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 CMMC practice 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 Limited. Generally, deficiencies should be resolved as soon as is reasonably possible. | |||
[m] 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.’ | |||
[n] For certain requirements, questions often arise on whether or not they are actually implemented. These situations are addressed below: | |||
:(1) Practices AC.L2-3.1.12, AC.L2-3.1.16, AC.L2-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 (CMMC Assessor) 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 ensure these capabilities are not enabled inadvertently. This should be discussed as part of Confirming the Assessment Outputs in paragraph 1.4.8, and if such policy and procedures are not in place a point should be assessed. | |||
:(2) CMMC Practice SC.L2-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) CMMC Practice SC.L2-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/CMMC). 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.’ | |||
[o] 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’. | |||
[p] A template illustrating the application of this scoring methodology is provided within this Appendix, paragraph K-2. | |||
== DoD Assessment Scoring Template == | |||
= DoD Assessment Scoring Template = | |||
[a] The following template illustrates the scoring methodology described in section K-1. If all requirements are MET, a score of 110 is awarded. For each practice NOT MET, the associated value is subtracted from 110. Consistency results from the fact that the assessments are based on what is not yet implemented, or document that all requirements have been MET. | [a] The following template illustrates the scoring methodology described in section K-1. If all requirements are MET, a score of 110 is awarded. For each practice NOT MET, the associated value is subtracted from 110. Consistency results from the fact that the assessments are based on what is not yet implemented, or document that all requirements have been MET. | ||
Line 288: | Line 155: | ||
|IA.L1-3.5.2* || Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. || 5 || | |IA.L1-3.5.2* || Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. || 5 || | ||
|- | |- | ||
|IA.L2-3.5.3 || Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts. || | |IA.L2-3.5.3 || Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts. || 5 || Subtract 5 points if MFA not implemented. | ||
|- | |- | ||
|IA.L2-3.5.4 || Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. || 1 || | |IA.L2-3.5.4 || Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. || 1 || |
Latest revision as of 22:03, 25 August 2022
Source of Reference: The NIST SP 800-171 DoD Assessment Methodology from the U.S. Department of Defense Website
For inquiries and reporting errors on this wiki, please contact us. Thank you.
DoD Assessment Scoring Methodology
[a] This scoring methodology is designed to provide an objective assessment of a contractor’s NIST SP 800-171/CMMC L2 Practice implementation status. Except for the practice for which the scoring of partial implementation is built-in (e.g., FIPS validated encryption, security requirement 3.13.11/CMMC Practice SC.L2-3.13.11) the methodology is not designed to credit partial implementation. However, partial credit can be applied for Derived Security Requirements that fall under practice SC.L2-3.13.11 - FIPS validated encryption, see paragraph “h” for additional guidance on partial credit for this practice based on how the practice is implemented.
[b] Conduct of the NIST SP 800-171 DoD Assessment Methodology on a CMMC L2 Assessments will result in a score reflecting the net effect of each CMMC Practice not yet implemented. If all CMMC practices are implemented, a contractor is awarded a score of 110, consistent with the total number of CMMC L2 Practices. For each CMMC Practice not met, the associated value is subtracted from 110. The score of 110 is reduced by practice not implemented, which may result in a negative score.
[c] 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.
[d] 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.
[e] 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/CMMC Practice AC.L1-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/CMMC Practice MP.L2-3.8.7) could result in massive exfiltration of CUI and introduction of malware.
- i. Basic Security Requirements/CMMC Practices with a value of 5 points include AC.L1-3.1.1, AC.L1-3.1.2, AT.L2-3.2.1, AT.L2-3.2.2, AU.L2-3.3.1, CM.L2-3.4.1, CM.L2-3.4.2, IA.L1-3.5.1, IA.L1-3.5.2, IR.L2-3.6.1, IR.L2-3.6.2, MA.L2-3.7.2, MP.L1-3.8.3, PS.L2-3.9.2, PE.L1-3.10.1, PE.L2-3.10.2, CA.L2-3.12.1, CA.L2-3.12.3, SC.L1-3.13.1, SC.L2-3.13.2, SI.L1-3.14.1, SI.L1-3.14.2, and SI.L2-3.14.3.
- ii. Derived Security Requirements with a value of 5 points include AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.16, AC.L2-3.1.17, AC.L2-3.1.18, AU.L2-3.3.5, CM.L2-3.4.5, CM.L2-3.4.6, CM.L2-3.4.7, CM.L2-3.4.8, IA.L2-3.5.3, IA.L2-3.5.10, MA.L2-3.7.5, MP.L2-3.8.7, RA.L2-3.11.2, SC.L1-3.13.5, SC.L2-3.13.6, SC.L2-3.13.15, SI.L1-3.14.4, and SI.L2-3.14.6.
[f] 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/ CMMC Practice MP.L2-3.8.2) or failure to encrypt CUI stored on a mobile device (Security Requirement 3.1.19/CMMC Practice AC.L2-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.
- i. Basic Security Requirements with a value of 3 points include AU.L2-3.3.2, MA.L2-3.7.1, MP.L2-3.8.1, MP.L2-3.8.2, PS.L2-3.9.1, RA.L2-3.11.1, and CA.L2-3.12.2.
- ii. ‘Derived Security Requirements’ with a value of 3 points include AC.L2-3.1.5, AC.L2-3.1.19, MA.L2-3.7.4, MP.L2-3.8.8, SC.L2-3.13.8, SI.L1-3.14.5, and SI.L1-3.14.7.
[g] 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.
[h] ‘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/practice is implemented.
- i. FIPS validated encryption (CMMC Practice SC.L2-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.
[i] Although not common, future revisions of NIST SP 800-171 and/or the CMMC Assessment Guide may add, delete, or substantively revise security requirements and CMMC Practices. When this occurs, a value will be assigned to any new or modified requirements in accordance with this scoring methodology.
[j] The contractor must have a system security plan (CMMC Practice CA.L2-3.12.4 ) in place to describe each covered contractor information system, and a plan of action (Practice CA.L2-3.12.2) in place for each unimplemented security requirement to describe how and when the security requirement will be met, not to exceed 180 days from the Assessment Final Recommended Findings Briefing (Phase 3).
- (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 SC.L2-3.13.11, FIPS validated encryption , is only 75% complete due to vendor issues, and there is a plan of action still being implemented, SC.L2-3.13.11 will be considered ‘not implemented’, as the requirement has not been fully implemented.
- (3) A lack of plan of action for unimplemented practices will result in CMMC Practice CA.L2-3.12.2 being assessed as ‘Not Met.’ During Phase 2 of the assessment process the OSC will populate CMMC Practice deficiencies on a POA&M to fulfill the objective level requirements for CMMC Practice CA.L2-3.12.2. Failure to generate an updated or complete POA&M document for the CMMC L2 assessment will result in CMMC practice CA.L2-3.12.2 being scored “NOT MET” and the CMMC L2 Interim Assessment Certification “Not Achieved.”
[k] Temporary deficiencies and/or isolated enduring exceptions which occur during initial implementation, or arise after implementation, are to be expected in most complex environments.
[l] 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., SC.L2-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 CMMC practice 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 Limited. Generally, deficiencies should be resolved as soon as is reasonably possible.
[m] 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.’
[n] For certain requirements, questions often arise on whether or not they are actually implemented. These situations are addressed below:
- (1) Practices AC.L2-3.1.12, AC.L2-3.1.16, AC.L2-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 (CMMC Assessor) 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 ensure these capabilities are not enabled inadvertently. This should be discussed as part of Confirming the Assessment Outputs in paragraph 1.4.8, and if such policy and procedures are not in place a point should be assessed.
- (2) CMMC Practice SC.L2-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) CMMC Practice SC.L2-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/CMMC). 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.’
[o] 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’.
[p] A template illustrating the application of this scoring methodology is provided within this Appendix, paragraph K-2.
DoD Assessment Scoring Template
[a] The following template illustrates the scoring methodology described in section K-1. If all requirements are MET, a score of 110 is awarded. For each practice NOT MET, the associated value is subtracted from 110. Consistency results from the fact that the assessments are based on what is not yet implemented, or document that all requirements have been MET.
[b] It is important to note an assessment is about the extent to which the company has implemented the practices. It is not a value judgement about the specific approach to implementing – in other words, all solutions that meet the CMMC practices are acceptable. This is not an assessment of one solution compared to another.
[c] Scoring for Basic, Medium, and High NIST SP 800-171 DoD, and CMMC 3rd Party Assessments are all the same.
[d] While NIST does not prioritize requirements in terms of impact, certain requirements do have more impact than others. In this scoring methodology security requirements/ CMMC Practices are weighted based on their effect on the information system and DoD CUI created on or transiting that system.
Practice Number | Practice Requirement | Value | Comment |
---|---|---|---|
AC.L1-3.1.1* | Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). | 5 | |
AC.L1-3.1.2* | Limit system access to the types of transactions and functions that authorized users are permitted to execute. | 5 | |
AC.L2-3.1.3 | Control the flow of CUI in accordance with approved authorizations. | 1 | |
AC.L2-3.1.4 | Separate the duties of individuals to reduce the risk of malevolent activity without collusion. | 1 | |
AC.L2-3.1.5 | Employ the principle of least privilege, including for specific security functions and privileged accounts. | 3 | |
AC.L2-3.1.6 | Use non-privileged accounts or roles when accessing non-security functions. | 1 | |
AC.L2-3.1.7 | Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. | 1 | |
AC.L2-3.1.8 | Limit unsuccessful logon attempts. | 1 | |
AC.L2-3.1.9 | Provide privacy and security notices consistent with applicable CUI rules. | 1 | |
AC.L2-3.1.10 | Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. | 1 | |
AC.L2-3.1.11 | Terminate (automatically) a user session after a defined condition. | 1 | |
AC-L2.3.1.12 | Monitor and control remote access sessions. | 5 | Do not subtract points if remote access not permitted |
AC.L2-3.1.13 | Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. | 5 | Do not subtract points if remote access not permitted |
AC.L2-3.1.14 | Route remote access via managed access control points. | 1 | |
AC.L2-3.1.15 | Authorize remote execution of privileged commands and remote access to security-relevant information. | 1 | |
AC.L2-3.1.16 | Authorize wireless access prior to allowing such connections. | 5 | Do not subtract points if wireless access not permitted |
AC.L2-3.1.17 | Protect wireless access using authentication and encryption. | 5 | Do not subtract points if wireless access not permitted |
AC.L2-3.1.18 | Control connection of mobile devices. | 5 | Do not subtract points if connection of mobile devices is not permitted |
AC.L2-3.1.19 | Encrypt CUI on mobile devices and mobile computing platforms | 3 | Exposure limited to CUI on mobile platform |
AC.L1-3.1.20* | Verify and control/limit connections to and use of external systems. | 1 | |
AC.L2-3.1.21 | Limit use of portable storage devices on external systems. | 1 | |
AC.L1-3.1.22* | Control CUI posted or processed on publicly accessible systems. | 1 | |
AT.L2-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. | 5 | |
AT.L2-3.2.2 | Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities. | 5 | |
AT.L2-3.2.3 | Provide security awareness training on recognizing and reporting potential indicators of insider threat. | 1 | |
AU.L2-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. | 5 | |
AU.L2-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 | |
AU.L2-3.3.3 | Review and update logged events. | 1 | |
AU.L2-3.3.4 | Alert in the event of an audit logging process failure. | 1 | |
AU.L2-3.3.5 | Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. | 5 | |
AU.L2-3.3.6 | Provide audit record reduction and report generation to support on-demand analysis and reporting. | 1 | |
AU.L2-3.3.7 | Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records. | 1 | |
AU.L2-3.3.8 | Protect audit information and audit logging tools from unauthorized access, modification, and deletion. | 1 | |
AU.L2-3.3.9 | Limit management of audit logging functionality to a subset of privileged users. | 1 | |
CM.L2-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. | 5 | |
CM.L2-3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | 5 | |
CM.L2-3.4.3 | Track, review, approve or disapprove, and log changes to organizational systems. | 1 | |
CM.L2-3.4.4 | Analyze the security impact of changes prior to implementation. | 1 | |
CM.L2-3.4.5 | Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. | 5 | |
CM.L2-3.4.6 | Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. | 5 | |
CM.L2-3.4.7 | Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. | 5 | |
CM.L2-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. | 5 | |
CM.L2-3.4.9 | Control and monitor user-installed software. | 1 | |
IA.L1-3.5.1* | Identify system users, processes acting on behalf of users, and devices. | 5 | |
IA.L1-3.5.2* | Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. | 5 | |
IA.L2-3.5.3 | Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts. | 5 | Subtract 5 points if MFA not implemented. |
IA.L2-3.5.4 | Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. | 1 | |
IA.L2-3.5.5 | Prevent reuse of identifiers for a defined period. | 1 | |
IA.L2-3.5.6 | Disable identifiers after a defined period of inactivity. | 1 | |
IA.L2-3.5.7 | Enforce a minimum password complexity and change of characters when new passwords are created. | 1 | |
IA.L2-3.5.8 | Prohibit password reuse for a specified number of generations. | 1 | |
IA.L2-3.5.9 | Allow temporary password use for system logons with an immediate change to a permanent password. | 1 | |
IA.L2-3.5.10 | Store and transmit only cryptographically-protected passwords. | 5 | Encrypted representations of passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords |
IA.L2-3.5.11 | Obscure feedback of authentication information. | 1 | |
IR.L2-3.6.1 | Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. | 5 | |
IR.L2-3.6.2 | Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. | 5 | |
IR.L2-3.6.3 | Test the organizational incident response capability. | 1 | |
MA.L2-3.7.1 | Perform maintenance on organizational systems. | 3 | |
MA.L2-3.7.2 | Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance. | 5 | |
MA.L2-3.7.3 | Ensure equipment removed for off-site maintenance is sanitized of any CUI. | 1 | |
MA.L2-3.7.4 | Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems. | 3 | |
MA.L2-3.7.5 | Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete. | 5 | |
MA.L2-3.7.6 | Supervise the maintenance activities of maintenance personnel without required access authorization. | 1 | |
MP.L2-3.8.1 | Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital. | 3 | Exposure limited to CUI on media |
MP.L2-3.8.2 | Limit access to CUI on system media to authorized users. | 3 | Exposure limited to CUI on media |
MP.L1-3.8.3* | Sanitize or destroy system media containing CUI before disposal or release for reuse. | 5 | While exposure limited to CUI on media, failure to sanitize can result in continual exposure of CUI |
MP.L2-3.8.4 | Mark media with necessary CUI markings and distribution limitations. | 1 | |
MP.L2-3.8.5 | Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas. | 1 | |
MP.L2-3.8.6 | Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards. | 1 | |
MP.L2-3.8.7 | Control the use of removable media on system components. | 5 | |
MP.L2-3.8.8 | Prohibit the use of portable storage devices when such devices have no identifiable owner. | 3 | |
MP.L2-3.8.9 | Protect the confidentiality of backup CUI at storage locations. | 1 | |
PS.L2-3.9.1 | Screen individuals prior to authorizing access to organizational systems containing CUI. | 3 | |
PS.L2-3.9.2 | Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers. | 5 | |
PE.L1-3.10.1* | Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals. | 5 | |
PE.L2-3.10.2 | Protect and monitor the physical facility and support infrastructure for organizational systems. | 5 | |
PE.L1-3.10.3* | Escort visitors and monitor visitor activity. | 1 | |
PE.L1-3.10.4* | Maintain audit logs of physical access. | 1 | |
PE.L1-3.10.5* | Control and manage physical access devices. | 1 | |
PE.L2-3.10.6 | Enforce safeguarding measures for CUI at alternate work sites. | 1 | |
RA.L2-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 | |
RA.L2-3.11.2 | Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. | 5 | |
RA.L2-3.11.3 | Remediate vulnerabilities in accordance with risk assessments. | 1 | |
CA.L2-3.12.1 | Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. | 5 | |
CA.L2-3.12.2 | Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. | 3 | |
CA.L2-3.12.3 | Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. | 5 | |
CA.L2-3.12.4 | Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. | NA | 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.’ |
SC.L1-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. | 5 | |
SC.L2-3.13.2 | Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. | 5 | |
SC.L2-3.13.3 | Separate user functionality from system management functionality. | 1 | |
SC.L2-3.13.4 | Prevent unauthorized and unintended information transfer via shared system resources. | 1 | |
SC.L1-3.13.5* | Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. | 5 | |
SC.L2-3.13.6 | Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). | 5 | |
SC.L2-3.13.7 | Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling). | 1 | |
SC.L2-3.13.8 | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. | 3 | |
SC.L2-3.13.9 | Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity. | 1 | |
SC.L2-3.13.10 | Establish and manage cryptographic keys for cryptography employed in organizational systems. | 1 | |
SC.L2-3.13.11 | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. | 3 to 5 | Subtract 5 points if no cryptography is employed; 3 points if mostly not FIPS validated |
SC.L2-3.13.12 | Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. | 1 | |
SC.L2-3.13.13 | Control and monitor the use of mobile code. | 1 | |
SC.L2-3.13.14 | Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. | 1 | |
SC.L2-3.13.15 | Protect the authenticity of communications sessions. | 5 | |
SC.L2-3.13.16 | Protect the confidentiality of CUI at rest. | 1 | |
SI.L1-3.14.1* | Identify, report, and correct system flaws in a timely manner. | 5 | |
SI.L1-3.14.2* | Provide protection from malicious code at designated locations within organizational systems. | 5 | |
SI.L2-3.14.3 | Monitor system security alerts and advisories and take action in response. | 5 | |
SI.L1-3.14.4* | Update malicious code protection mechanisms when new releases are available. | 5 | |
SI.L1-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 | |
SI.L2-3.14.6 | Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. | 5 | |
SI.L2-3.14.7 | Identify unauthorized use of organizational systems. | 3 |
- Basic safeguarding requirements and procedures to protect covered contractor information systems per Federal Acquisition Regulation (FAR) clause 52.204-21, Basic Safeguarding of Covered Contractor Information Systems.