More than half of all assessment requirements in NIST SP 800-171a rest on asking Organizations Seeking Certification (OSCs) to “identify,” “define,” or “establish” certain variables in their documentation stack.
When addressing these assessment objectives, ‘the power of definition’ can become an important tool for OSCs to leverage.
This ‘power’ allows organizations to define crucial parameters for themselves as they document their information security architecture. C3PAOs assess against these variables as defined by the OSC in their documentation, as long as the definition is reasonable; therefore, the best chosen definitions have their basis in reputable precedents, such as government publications or the NIST Glossary.
Well crafted, well-documented definitions help to manage an OSC’s compliance burden, streamline documentation processes, and support employees during third-party assessments. However, as always when addressing CMMC documentation requirements, it is important to 'do what you say and say what you do.'
Below I consider 10 key locations an OSC may apply the ‘power of definition’ to the security requirements in the most current version of 171a. While this is not an exhaustive list, it is a good starting point to begin understanding how your organization may adjust these variables to its advantage.
Where Can I Apply the Power of Definition?
1.AC 3.1.7[a] privileged functions are identified.
This assessment objective gives the OSC the power to define “privileged functions.” To limit compliance risk when defining “privileged functions,” an OSC may choose to describe them narrowly.
For example, "privileged functions are defined as domain admin functions in Active Directory." With this definition in place, the OSC may subsequently refer to Microsoft's own documentation as further evidence.
How your organization chooses to address this assessment objective may have implications for 3.1.5[a] “privileged accounts are identified” and [c] “security functions are identified.” This correlation is (in part) due to inconsistencies in the methodology NIST uses to parse out assessment objectives from controls—but that is a topic for another day.
*Microsoft’s suite of tools is not required to satisfy this assessment objective or any other. We use it as an example throughout this write-up as a means of modeling how a tool or tools might be used to meet 171 requirements. DCG is a Google Workspace company seeking a CMMC certification based on G-Suite. Contact us for further information on how we are configuring a compliant Google environment.
2. AC 3.1.7[b] non-privileged users are defined.
This assessment objective gives the OSC the power to define “non-privileged users.” As we often do, DCG recommends defining this narrowly to limit compliance risk.
For example, an OSC may define non-privileged users as "all users that are not privileged users or domain admin accounts." This allows the OSC to point to standard Microsoft account functionality for 3.1.7[c] “non-privileged users are prevented from executing privileged functions.”
*As indicated above, inconsistencies in how NIST pulled assessment objectives from controls has created some endogamy throughout 171a. OSCs should always look at how this may impact the manner in which they choose to define other variables.
*Microsoft’s suite of tools is not required to satisfy this assessment objective or any other.
3. AC 3.1.11[a] conditions requiring a user session to terminate are defined.
The most common reference we recommend to OSCs to harness the ‘power of definition’ is the NIST Glossary. This particular glossary has the benefit of being “NIST canon,” making it extremely unlikely an assessor will challenge a variable with its foundation here.
The NIST Glossary provides different definitions for a "user session," but at its core, a user session is a connection between two computers.
3.1.11[a] asks the OSC to define what conditions indicate a session must be terminated. One way to approach this is to name a particular kind of session that occurs regularly (e.g. when connecting to SharePoint) and use this as the only kind of session "requiring termination."
This example offers the benefit of connecting directly to SP's ability to configure session termination settings. Therefore, evidence is readily available to support the claim that what you have defined as requiring termination is, in fact, terminated automatically. VPNs are another example of something that can be utilized here to satisfy the assessment objective while limiting compliance risk.
4. AC 3.1.12 [b] the types of permitted remote access are identified.
In other words, you get to decide what "types of permitted remote access" means. For example, the OSC might identify "VPN access" as the permitted type of remote access.
*See discussion of 3.1.11[a].
5. AU 3.3.1 [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified.
"Are specified," like "are defined," means that the data in question must be written down in the OSC's documentation stack somewhere. Most often, we recommend addressing this at least in your organization’s SSP.
From a compliance-risk perspective, it is best practice here to prescribe a limited set of logs as "necessary" even if the OSC collects additional information for enhanced security. A very limited, very provable list often serves OSCs best when attempting to satisfy this assessment objective. For example, "firewall logs" with event types named being "time up, time down, and connection type."
Of course, additional information is often (and should be) collected. However, the core of this particular objective is that the OSC gets to define what they consider "needed."
6. CM 3.4.2 [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration.
In addition to the baseline configuration requirements discussed in 3.4.1, security configuration settings are added to the list in this assessment objective. The OSC maintains the ‘power of definition’ in this case; you get to decide what those settings are. For example, placing a laptop in "FIPS mode" is a common security configuration setting. It is often recommended, to limit compliance risk, that this list remain relatively short.
7. IA 3.5.5 [a] a period within which identifiers cannot be reused is defined.
"Identifier" is defined in the NIST Glossary as: "unique data used to represent a person’s identity and associated attributes. A name or a card number are examples of identifiers." Another common example of an identifier is a username. Best practice would be to define this period as being at least one year. "Are defined" indicates that, in the SSP or elsewhere, the OSC must explicitly name the chosen time period.
8. IA 3.5.7 [a] password complexity requirements are defined.
Examples of password complexity requirements include: 14 characters, at least one number, upper and lowercase letters, at least one special character, and so on.
In this case, the assessment objective is written such that the power of definition lies with the OSC. However, cybersecurity best practice strongly recommends that passwords be at least 14 characters long.
In the age of modern computing, greater password length is the only complexity requirement proven to strengthen information security. The longer your password, the more secure you will be; adding numbers or special character requirements has not been proven to bolster these protections beyond their capacity to add length. By contrast, requiring employees to change their passwords more often than annually has been proven to weaken information security.
9. IA 3.5.7 [b] password change of character requirements are defined.
"Password change of character requirements" indicates how different one password must be from its following iteration.
For example, say User YXZ's first password is Password123. When it comes time for them to update this password, is it acceptable for User XYZ to change their password to Password124? What about Password456?
In the first example, only one character changes. In the second example, three characters change. At its core, 3.5.7[b] is asking: according to the OSC, how many characters must change between one password iteration and the next? How similar can they be to one another?
Write your answer down somewhere in your documentation, e.g. in the SSP. If the OSC uses AD, note that this tool natively only allows one-character changes, and cannot at the time of this writing be configured otherwise. Therefore, defining "password change of character requirements" as one character is the compliant, provable means of satisfying this assessment objective for companies utilizing MS Active Directory.
*Microsoft’s suite of tools is not required to satisfy this assessment objective or any other.
10. CA 3.12.2 [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified.
"Are identified" indicates that the deficiencies and vulnerabilities in question must be written down somewhere. Because 3.11.2 requires the OSC to scan for vulnerabilities, reference 3.11.2 implementation when discussing address of vulnerabilities.
DCG recommends deficiencies be broadly understood as "problems" with the system you'd like to remediate, from an out-of-date policy to a weak point in a process.
Note there is no standing definition for "deficiencies" in the NIST Glossary or the CMMC Glossary at the time of this writing, and that the power of definition remains with the OSC. However you choose to define deficiencies, be sure to carry this definition through the remaining assessment objectives associated with 3.12.2. Regardless of your chosen definition, developing a tracking mechanism for such deficiencies and vulnerabilities is necessary to meet this control.
Comentarios