CMMC and the POAM– Are POA&Ms really not allowed?
Has the use of the Plan of Actions and Milestones (POA&M) changed based on CMMC?
CMMC v1.0 has officially been released as of Friday, January 31, 2020. One topic that has really spun up debate and angst is the status of the plan of action and milestones (often abbreviated as POAM or POA&M). Statements like “POA&Ms are not envisioned in the CMMC”, and “POAMs are prohibited” are being circulated. What does all this mean?
Clarification Language on Plans of Action from CMMC v 1.0
The angst is coming from practice CA.2.159 as detailed in Appendix B of the CMMC v1.0 Appendices (as well as earlier versions). Appendix B provides “discussion, clarifications with examples, and associated references for each process and practice in the CMMC model.”
For CA.2.159, from page B-188, the discussion from source reads as follows:
CA.2.159: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
Discussion From Source: Draft NIST SP 800-171 R2
The plan of action is a key document in the information security program. Organizations develop plans of action that describe how any unimplemented security requirements will be met and how any planned mitigations will be implemented…
…Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization.
Emphasis mine. From this, we see that DRAFT NIST SP 800-171 R2 describes a process where unimplemented or deficient requirements can be POAM’d. Federal agencies then use the POAM (and other inputs) to make a risk-based decision on whether to contract with the organization.
However, in the next section, CMMC Clarification there’s this:
Note that receiving Cybersecurity Maturity Model Certification requires all practices and processes to be implemented at the time of assessment. Any security requirements that were part of a plan of action must be closed/met in order to be granted the CMMC assessment.
Again, emphasis mine. This seems to be in direct contradiction to the draft language from 800-171 above, right? Well, not exactly. Fortunately, this seeming contradiction is cleared up in the examples provided:
You are in charge of IT operations in your organization. Your job is to develop action plans when you discover that your company isn’t meeting security requirements. One of your sources of information is the output of vulnerability scans on your network. When you receive notification of a vulnerability that needs fixing, you develop a plan to fix it. Your plan identifies the person responsible for fixing it, how to do it, and when to do it. You will also define how to measure that the person responsible has fixed the vulnerability. You document this in a plan of action.
Ok, so from that its clear that vulnerabilities discovered in scans are still expected to be documented and managed in the POAM. Overall, the POAM is still alive, and having POAMs related to scan findings doesn’t seem to be disqualifying. Next example.
A company that is CMMC L1 compliant seeks L3 compliance. The IT department tracks the implementation of the additional security requirements needed for L3 in an action plan and realizes that it will be more than 6 months before CMMC L3 requirements can be met. Company officials refer to the action plan that indicates that CMMC L2 requirements are currently met and decide to pursue CMMC L2 compliance instead of L3 and seek L3 certification next year.
So, the POAM is still used to track deficiencies, but you can’t have open POAM items for requirements in the level (or levels below) that you are attempting to certify against.
But here is the real insight…
It’s all about the CMMC Levels!
CMMC introduces the concept of levels, and this is the real key to understanding this seeming contradiction. The 800-171 language describes a risk-based approach to be performed by each contracting agency to determine if it is safe to use a contractor. Among the problems with this approach:
- Enforcement is left up to the agency via acquisition rules. Contracting offices aren’t always equipped to effectively conduct these audits, so the results and effectiveness varies.
- Contractors must demonstrate compliance to each agency leading to inefficiencies.
CMMC seeks to address these problems by:
- Creating an accredited, external, third-party auditor and accreditation body to relieve the contracting offices,
- Moving to an “assess once, use many” process,
- Providing a framework for categorizing a contractor’s risk rating via CMMC levels.
However, the CMMC levels concept would be compromised if some contractors could POAM certain requirements and still obtain a desired CMMC level. In this context, this new rule can be seen as an attempt to create a level playing field and to ensure that the CMMC levels remain meaningful.
But will it work?
There’s been a lot of discussion around the InfusionPoints’ water-cooler as to what this "no POAMs rule" will mean, and how well it will work out in practice. Points of discussion have included:
- Appearance that this is a pre-emptive strike to maintain meaningfulness of the CMMC levels by preventing contractors from just opting to POAM the requirements where they are non-compliant instead of doing the hard work to comply from the outset.
- Concern that the lower CMMC levels be rendered less meaningful because so many DoD contracts will likely fall to level 3 at a minimum, with the larger prime arrangements being at levels 4 and 5? Or in other words, level 2 doesn’t make such a good consolation prize if you barely missed level 3 and nearly all contracts require it.
- Risk-based decisions seem to work best when a balance between risk and reward is well understood by the decision maker (e.g. left up to the agency, de-centralized). What effect will this have on DoD missions?
Its hard to envision the same kind of zero tolerance policy working for FedRAMP -- where any of the FedRAMP controls that have POAMs would block an ATO. Traditionally in FedRAMP (and risk management in general for that matter), this is where the risk ratings for noted deficiencies have come into play, where moderate and low rated findings have not been showstoppers. Also, zero tolerance flies in the face of conventional wisdom in cybersecurity where there is the notion of security as a process and continuous improvement. Isn't this in-fact the hallmark of DoD’s Risk Management Framework (DoD RMF) – the centerpiece of the DoD’s approach to Cybersecurity? Could this have the effect of disincentivizing contractors to improve processes that are already working well, or force them to only acknowledge these improvements off of the official POAM?
As one observer summarized in a comment on a related LinkedIN post:
How many systems the gov owns wouldn’t be running without POA&M though. Quite a bit of what’s good for the goose is not good for the gander.
Ultimately, time will tell…