Documenting NIST 800-171 and CMMC

During the Cybersecurity Maturity Model Certification (CMMC) Accreditation Body (AB) September Town Hall, Nick DelRasso from the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) stated that some companies didn’t understand they had to document how something was implemented vice just saying it was implemented. He went on to say they see a lot of rehashing of the requirements in implementation procedures. For example (mine not his), if the requirement is:

3.9.1.a. Individuals are screened prior to authorizing access to organizational systems containing CUI.

Your implementation procedure shouldn’t read: “Our Company screens individuals prior to authorizing access to organizational systems containing CUI.” That doesn’t provide any guidance on how that screening is conducted, managed, or monitored.  And is useless for someone trying to implement the control or assess it.

The purpose of implementation procedures is not to appease assessors, they are meant to allow employees to pick up the procedure in the future and be able to quickly ascertain how to implement the control. A better implementation procedure would be:

3.9.1.a. The Information Owner is responsible for verifying that background screening has been performed on users prior to authorizing them System access; and rescreening individuals prior to granting an elevated change in role.  The Company will utilize one of the following three methods to screen users: 1) Rely on the U.S. Government screening process and trust individuals with active security clearances as verified by the FSO in DISS. 2) Conduct a background screening through a background investigation service as verified by Human Resources (HR). 3) Rely on partner verification that a background investigation has been conducted for subcontractors, partners, and others outside of the company requiring access to CUI as verified by the partner HR office.  All new employees will undergo background screening as part of their onboarding process.

Policies lay out the who, what and why.  Procedures describe the when, where, and how. As in the above example, your company Physical Security Policy should lay out who’s in charge of security within your organization. What the scope of their responsibilities are and what the company’s security objectives are. And finally, why security is important to your organization. The policy, once published, may not change much year after year.  With that policy in hand, the responsible individual has the authority to implement procedures that meet the goals laid out in the policy. Procedures should provide detailed when, where and how instructions and may change frequently.

For example, your Physical Security Policy states that “The company building will be physically secured and monitored to protect personnel and property.”  The Procedures would then provide instructions on how the building will be secured and provide detailed information on subjects such as: 

• Observation

  • Cameras

    • Placement of video surveillance cameras. 

    • Manufacturer and model of cameras.

    • Instructions on who has access to the cameras and how they will be used.

    • Service contract info and point of contact.

  • Alarm System

    • Location of alarms and motioned detectors.

    • Manufacturer and model of alarm system.

    • Service contract info and points of contact.

    • List of personnel to be alerted if the alarm trips.

  • Access Logs

    • System used to log access.

    • Instructions on who has access to the logs and how often they will be reviewed.

• Barriers

  • Locks

    • Type of lock on each door.

    • Key/FOB/Code control procedures.

    • Service schedule

As you can see the simple statement of securing the building expands into detailed instructions on the how, when and where that will be accomplished.

There are many ways to document the 800-171 controls and objectives. A single system-wide document, multiple documents grouped by security control family, or a hybrid approach.  We’ve found that an overarching System Security Plan (SSP) supported by a suite of corporate polices and implemented through implementation procedures is the most usable.

The SSP should begin with a Word document that describes the system characteristics and implementation and be paired with an Excel spreadsheet that provides detailed control implementation down to the objective level. NIST provides a rudimentary template at CUI-SSP-Template-final.docx (live.com). Ascolta offers a free Microsoft Excel spreadsheet SSP that calculates Supplier Performance Risk System (SPRS) scores and provides an executive level dashboard.

The corporate policies provide the authority for the IT department to implement the procedures to achieve certification. A list of policies starts with the following:  

• Acceptable Use Policy

• Asset Management Policy

• Configuration and Change Management Policy

• Cyber Incident Response Policy

• Data Handling and Storage Policy

• Encryption Policy

• Maintenance Policy

• Mobile Device Po9licy

• Password Policy

• Personnel Policy

• Physical and Environmental Protection Policy

• Remote Office Policy

• Risk Assessment Questionnaire

• Risk Management Mitigation Plan

• Risk Management Mitigation Policy

• Secure Engineering Principles Policy

Finally, the implementation procedures provide the nitty gritty details of how each objective is met and should be the reference source or artifact for most controls. They can be organized in many ways, but we’ve found the NIST security families are as good as any: 

• Access Control Implementation Procedures

• Awareness and Training Implementation Procedures

• Audit and Accountability Implementation Procedures

• Configuration Management Implementation Procedures

• Identification and Authentication Implementation Procedures

• Incident Response Implementation Procedures

• Maintenance Implementation Procedures

• Media Protection Implementation Procedures

• Physical Protection Implementation Procedures

• Personnel Security Implementation Procedures

• Risk Assessment Implementation Procedures

• Security Assessment Implementation Procedures

• Systems and Communications Protection Implementation Procedures

• Systems and Information Integrity Implementation Procedures

When it’s all said and done, you’re looking at a minimum of over 240 pages of documentation. That’s only a few weeks’ worth of full-time writing, coordinating, and staffing if you are a company lucky enough to have the correct resources on staff to address and answer all the required questions. I hope you’re not starting from scratch!