Doing the Do: Verbs and the Source of Truth with Your System Security Plan

When writing a NIST-SP-800-171 System Security Plan we have a mantra, “Say what you do, Say how it gets done, Prove you do it.”

Lot of action in that sentence, but in the end six verbs drive how you protect the confidentiality of Controlled Unclassified Information (CUI) in your system:

• Defined
• Specified
• Identified
• Established
• Documented
• Developed

These verbs denote a declaration of a “thing.” Then your System Security Plan points to a source of truth on the subject or thing, the security requirement. Often this happens directly in the System Security Plan and other times you point to a policy, plan, or procedure.

• Defined- Clearly stated explanation of exactness or fixed limits
• Specified- A condition, quantity, frequency, method, or constraint stated precisely enough to implement and test.
  
• Identified-The applicable people, roles, devices, events, connections, can be named or listed with a specificity that allows testing
  
• Established- A policy, process, baseline, capability, or organizational arrangement has been formally instituted and put in place which can be verified through testing.
  
• Documented- The required information, decision, event, result, or action has been recorded in a retrievable form.
  
• Developed- A required plan, process, capability, or artifact has been created and sufficiently elaborated for its intended use.
  

Across NIST-SP-800-171a almost every security requirement includes one of these six verbs in the first one or two objectives. You have to say what you do to have a System Security Plan

Real World Example

Let us examine the requirements around a password in NIST-SP-800-171a

NIST SP 800-171 Rev. 2 Requirement 3.5.7 states:

“Enforce a minimum password complexity and change of characters when new passwords are created.”

You need to prove how you enforce password complexity and you can not enforce what you do not define, so we turn to the assessment objectives.

In the first two objectives 3.5.7[a] and [b] you get to define the rules.

The organization decides what complexity means and how much a new password must differ from the previous password. The next two objectives [c] and [d] enforce the rules you just defined. Technical mechanisms must prevent users from creating passwords that violate those defined requirements.

So you do not define “Change of characters” as a password-expiration period. You must explicitly restate how many characters must differ when a user creates a replacement password. Password reuse history is addressed separately by 3.5.8.

NIST-SP-800-171a rev 2 dictates what you must define, but not where that definition lives. If you do not want a ton of new documentation you can 100% define all this directly in the SSP. Nobody says you must have a password policy.

3.5.7[a] — Password-complexity requirements are defined.

The organization defines a compliant password as one containing at least 15 characters, including at least one uppercase letter, one lowercase letter, one number, and one special character. Passwords may not contain the user’s account name, the organization’s name, or commonly used or compromised passwords.

3.5.7[b] — Required change of characters is defined.

When a password is changed, the organization requires the new password to differ from the immediately preceding password by at least four characters. Changing only capitalization does not satisfy this requirement.

3.5.7[c] — Password-complexity requirements are enforced.

The organization’s centralized identity-management system technically enforces the defined minimum password-complexity requirements. The password-policy engine evaluates proposed passwords during password creation and reset and rejects passwords that do not satisfy the minimum length, character-type, prohibited-content, and compromised-password screening requirements. Users cannot override the password-policy engine.

3.5.7[d] — Character-change requirements are enforced.

The identity-management system’s password-policy engine compares each proposed password with the user’s immediately preceding password. The system rejects the proposed password when fewer than four characters have changed or when the difference consists only of capitalization. The password cannot be activated until the defined character-change requirement is satisfied.

Some companies who must meet multiple regulatory frameworks may want to keep their definitions outside of the SSP so if they make a change the System Security Plan does not drift. You can point to the source of truth in your SSP and not include the definition.

3.5.7[a] — Password-complexity requirements are defined.

_The organization’s minimum password-complexity requirements are defined in the Identification and Authentication Plan, Section 7.3, “Password Composition and Complexity Requirements.” which identifies the applicable account types and defines the minimum length, permitted and prohibited characteristics, character-composition requirements, and prohibited-password screening requirements.

3.5.7[b] — Required change of characters is defined.

The required change of characters between the current password and a newly created password is defined in the Identification and Authentication Plan, Section 7.3.2, “Password-Change Requirements.” The defined requirement applies to user-initiated password changes, administrative password resets, and password changes following account recovery.

3.5.7[c] — Password-complexity requirements are enforced.

The organization enforces the password-complexity requirements defined in the Identification and Authentication Plan through the technical configuration and administrative procedures established in the Password Policy, Section 6.2, “Password-Complexity Enforcement.” The centralized identity-management system evaluates proposed passwords and rejects passwords that do not satisfy the defined requirements. Section 8 of the Password Policy requires administrators to periodically verify the configuration and retain the resulting evidence.

3.5.7[d] — Character-change requirements are enforced.

The organization enforces the character-change requirements defined in the Identification and Authentication Plan in accordance with the Password Policy, Section 6.3, “Password-Change Enforcement.” The password-policy mechanism evaluates proposed passwords against the preceding password and prevents activation when the defined minimum character change has not been achieved. Configuration changes, exceptions, verification activities, and corrective actions are managed and documented under Sections 7 through 9 of the Password Policy.

Either option works in your SSP. You utilize the System Security Plan as a source of truth or you point to the source of truth.

“Passwords” flickr photo by paul.orear flickr.com/photos/pa… shared under a Creative Commons (BY-SA 2.0) license