Ah, documentation. The most beloved part of every cybersecurity and IT professional's day. If only they could have more paperwork, then their joy would finally be complete.
Right? Right?
Perhaps not. Many technical people consider documentation the lousiest part of their job. Unfortunately, when it comes to compliance (and CMMC Level 2 in particular) documentation makes up the majority of the work.
I want to repeat that for emphasis, as this is a critical point for executives and implementers in the CMMC community. Documentation = the majority of the work to remain compliant. Conversely, technical implementation is NOT the majority of the work.
Almost universally (in my experience), everyone starts working on technical implementation first. It's not uncommon to hear: “We will take care of documentation later. That’s the easy part.” While this assumption is intuitive, it is also very wrong, as documentation is the majority of the work. There is nothing wrong with starting technical implementation first, and in fact, some documentation cannot be drafted in its absence. But realize: documentation is the majority of the work. Do not push it off until the end or treat it as an afterthought significantly easier than technical implementation.
Documentation is the majority of the work. “The work” is a lot of work.
As a ROM for this, consider that you must have at least 300-500 pages of documentation. The stack describes your implementation of all 320 assessment objectives in 800-171a in detail. If you have less than that, you should probably be looking hard at whether or not your stack is enough to pass a CMMC Level 2 audit/assessment.
Worse, once you have your tome written, you must update it at least annually. The documents must continue to represent your architecture, controls implementation, processes, and procedures as they exist today. In other words, you cannot write your 300-500 page thesis and have it stand for all time, or even for several months, without some kind of update.
This is a heavy burden, especially for small and medium-sized businesses where these efforts fall on overhead. There are some efficient means of approaching documentation (and we discuss a few recommended approaches below), however, not much changes the fact that this is a lot of work which must be done by someone in order to gain and maintain CMMC certification.
So how should we approach this heavy burden? How many documents should we have? Should we buy templates? What other kinds of help are available to the DIB?
Documentation Guidance
1. Add the Assessment Objectives to your SSP.
You must have a Systems Security Plan (SSP). This is the single most important document. There are specific requirements for what needs to be in an SSP. NIST has published a perfectly serviceable template for free here: https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final. The use of this template is not mandatory but about 90% of people start with this and we highly recommend using it.
In Section 3 of the NIST template, the Organization Seeking Certification (OSC) is asked to explain how it meets each of the 110 controls. Add the assessment objectives (AOs) from 171a.
According to my lead technical writer, this is the most important piece of advice in this article.
After you’ve added the AOs, write to how you meet each one. The single biggest mistake OSCs make is not paying attention to the assessment objectives. You must track your program down to the assessment objective level or you will fail a CMMC assessment.
You might be saying: “Wait, what? DFARS says I have to do 171 so screw 171A!” I feel your sentiment. But as constructed, CMMC requires you to meet each assessment objective under a control for that control to be assessed as “MET.” In other words, failure to meet a single assessment objective results in a finding of “NOT MET” for the control. Failure of a single control can translate to failure of the entire CMMC assessment. And here is the kicker: the assessment objectives add new work in many cases, so if you just look at the controls, you will not know everything you need to do and – you – will – fail.
In order to avoid this, write in 1) the assessment objectives for each control, in addition to 2) how you are meeting them. Having the assessment objectives in there ensures you are tracking all required program components.
2. Add a signature block to your documents.
No, a signature block is not required, but it is the easiest way to show when this was done and that it is approved and final. Much of a CMMC assessment boils down to “show me.” Generating evidence that you are doing things should always be a part of your consideration, and a signature block provides evidence that a given piece of documentation is approved and in force. The old CMMC 1.0 maturity requirements are gone, but I still think this is a really good thing to do. It drives a “final” version at a point in time. It makes you prepare it for the boss to sign. It is a good system that keeps organizations accountable to their documented processes.
3. Add a change log to your documents.
Since documents are supposed to be updated periodically, and CMMC defines periodically as “no longer than annual” in the CMMC Glossary, the general assessor approach is that more than a year old = bad. The change long is a handy place to provide the assessor evidence that the SSP, and other documents are being updated every year. Again not strictly required but a really really good idea.
4. Follow the Assessment Objective requirements for SSPs.
There are assessment objectives for SSPs! Oh glorious day. So you better have all of those “MET” or you will fail your assessment. Those assessment objectives are:
“[a] a system security plan is developed;” So you must have a document.
“[b] the system boundary is described and documented in the system security plan;” Generally this is done with a system diagram in Section 2 System Environment of the NIST Templated SSP.
“[c] the system environment of operation is described and documented in the system security plan;” Again section 2.
“[d] the security requirements identified and approved by the designated authority as non-applicable are identified;” There is a spot for this in the template. They can be identified as “None” and generally that is what I recommend. Per DFARS 252.205-7012 anything marked “Not Applicable” requires the DoD CIO’s written permission. The general position of assessors is that it is better to mark things as Met and then explain how you would deal with the control if that ever came up. The classic example is wireless controls when you have no wireless but there are others. If you have the DoD CIO’s written permission however you can mark something as NA.
“[e] the method of security requirement implementation is described and documented in the system security plan;” This is done in section 3 where they list 110 controls. Control = Security Requirements in my usage. 171 actually calls the list of 110 things you have to do security requirements. So that listing in section 3 of the NIST template is mandatory. I have seen a few organizations deal with these as a spreadsheet rather than in the word based template. Assessors in general won't care as long as it is adequately documented. I still recommend using the NIST word template.
“[f] the relationship with or connection to other systems is described and documented in the system security plan;” This one can get missed because the NIST template does not have a spot for it. Add it to section 2. You will also need this for CMMC scoping covered later.
“[g] the frequency to update the system security plan is defined;” Throughout the assessment objectives there are words like defined, identified, and designated. These are verbs you need to pay close attention to. In practice, ‘defined’ means “is written down in the documentation somewhere.” Max for this is annually per the CMMC definitions in the eyes of most assessors. Make sure to write down, “This plan is updated at least annually,” somewhere.
“[h] system security plan is updated with the defined frequency.” Now the record of changes section becomes a nice place to show evidence of this. These last two assessment objectives follow the pattern that is true throughout 171. First, define what you do, then do it. When doing it, be sure the doing generates evidence that it is done. You will have to prove with evidence to assessors that this is so.
5. Templates
In general, I am not a template fan for companies to purchase, especially without help. I have seen companies put forward blank templates as sufficient. That will NOT work for CMMC. Even lightly filled out, generalized “we do cyber!” will not work. A method in the certification world is to fill out templates with long-winded phrases that say little to nothing of substance, but appear well written and limit legal liability. The whole idea is to obfuscate anything an assessor might try to hold you accountable for. They say nothing about specific systems and implementations because those change, and then the documentation has to be changed. This works in a lot of instances and many executives are experienced with this approach of minimum investment to achieve the desired certification. That will not work for CMMC.
With that said, some templates can help some companies, if they acknowledge that they will need to be tailored in detail for your company. They can also be a very expensive fail if not used correctly.
Some larger organizations may benefit from the purchase of templates, given dedicated staff time and processes to develop and maintain them, and given the selection of the right template stack for the company.
6. Limit the number of documents
My observation is that many working seriously on this have too many documents. This is one of the issues I have with purchased templates. It is also why, if you choose to go that route, choosing the right option is both crucial and challenging.
You pay a lot of money for a reputable template set. They send over 120 distinct documents each of which has to be filled out, tailored, and most importantly maintained over time. They each must be touched and updated at least annually. That is 2-3 documents updated and resigned per week, every week of the year, if you keep the full stack of template documents. Every document you produce will have a certain number of overhead hours associated with just bringing it up, reviewing it, pushing it through the chain for approval (and hopefully signature), and so on.
Limit the number of documents you create and use for CMMC. Seriously.
One way that I recommend doing this (and please feel free to call me a heretic in the comments), is by not having too many types of documents. The academic and industrial standard practice for this is Policies, Standards, Procedures, and Guidelines. When I took my master's course on IT governance, this is what they taught.
Applying that to a CMMC case, take something like the Access Control domain. Under this framework, you might have a policy that covers high-level stuff, a standard that says “these things shall be done,” a procedure that says “this is how we do it,” and guidelines with good ideas that are not mandatory. My recommendation: don't have four different documents that all cover the same control set.
A. One policy to rule them all
My recommendation is to have one overarching Cybersecurity policy that covers all domains explicitly. This can be high level (i.e. not a lot of specifics) and not change that frequently. It needs to be updated at least annually and be able to demonstrate that it is in use and available to users. A Word document, stuck in a personal drive, with track changes, that no one can access will probably not be seen as valid documented evidence of policy and there are a few controls that specify policy is needed. It checks the policy block.
B. Combine as much as possible
Then combine standards, procedures, and guidelines into a single document on a per-domain basis (in general). You can have those as three sections in the document if you like, although that is not a CMMC requirement. In some cases, you can combine domains, and depending on your size, you might elect to just put all needed items for that domain in the SSP. Awareness and Training is one domain where that might be a good fit. There is no hard and fast rule on the structure, just that everything that needs to be documented per the assessment objectives is documented somewhere.
C. Add other things as needed
There are some places where we generally create separate documents that support compliance. One is the Acceptable Use Policy or Agreement or whatever you call it. That document tells users what they can and cannot do with your IT system. Some companies have this in their employee handbook. For example in one company that had a strong employee handbook process that already spoke to IT, we simply strengthened that rather than write a new thing.
The second document we normally recommend that is additional is the Remote Work Procedure. This covers how you handle dealing with CUI outside of the office. There are a handful of controls where this is the way to meet them in our view. Not strictly required. A really good idea.
D. Don’t Write a set of policies for every compliance standard
Companies do this all the time. They have a stack of CMMI policies that get looked at every three years when CMMI comes up for renewal. They have a stack of ISO policies that get looked at when they come up for renewal. Etc etc. The tendency, in some larger orgs, is to create a new set of policies specific to CMMC following the same model. We strongly recommend against this.
The common method of writing an eloquent set of high-level policies and then ignoring them until the next certification will NOT work for CMMC. The “show me” aspect of providing proof that you are executing on those policies in specific ways will penetrate that veil in a heartbeat. We have to not only write these documents, but they must represent things that we are actually going to do on an ongoing basis. As a result, this can cause collisions with ISO and CMMI requirements, for example, meaning we have to integrate those effectively. Having three different policies on Access Control for example is not the way to go.
7. There are no hard and fast rules
CMMC has not specified how documentation should be done beyond some basics. You must have an SSP and it must meet the stated requirements. You should have policy covering every domain but that is not explicitly assessed (this requirement does exist in Appendix E of 171 that most people don't look at and many would need a NIST speak translator to understand but it is not assessed). Assessors for the most part don’t care if you call something a policy, a plan, agreement, handbook, manual, etc etc. As long as the necessary processes are documented and then you have evidence that they are carried through on. We often say "have one 500 page document, or 500 documents of one page, it does not matter." Keep in mind “Say what you do,” and “Do what you say,” as the basic model.
Comentários