Art Clomera,
CTO, Federal Services –
Wouldn’t perfection be great?
Everyone, every organization, every system working exactly the way they should with inexhaustible, flawless precision from the word “Go.” Never worrying about something not going exactly as planned. It sounds pretty great but also pretty impossible… (even boring). Perfection in the world of cyber security is impossible because 1) we’re all human and 2) both sides of the adversarial divide are striving for it. There can be no perfect attack and a perfect defense.
In reality, neither side expects that they can be truly perfect – at least not for very long – but they try as hard as they can to get there by working on their imperfections. As one side reaches their summit, the other raises the bar, starting the climb again.
The Federal Information Security Modernization Act of 2014 (also FISMA) requires all agencies to envision and achieve the closest approximation of cyber security “perfection” they can for their specific roles, systems, and missions: their risk posture. They do this by following the National Institute of Standards and Technology’s (NIST) Risk Management Frameworks (RMF). RMF includes Plan(s) of Action and Milestones (POA&M, or POAM) specifically to deal with those areas where agencies fall short of the goal. As much as we’d be delighted to never need them, POAMs are ubiquitous with RMF and critical for agencies’ security success.
Read on for a crash course on POAMs: what they are, why they’re important, and what information you need to complete them.
What is a POAM?
Plan of Action and Milestones, or POAM, is the corrective action component of federal agencies’ cybersecurity Risk Management Framework (RMF) Authorization Package (AP). They come in the form of a preformatted spreadsheet template with columns designated for different data points. POAMs are part of the Security and Assessment and Authorization Control Family, specifically listed under Control CA-5 in NIST Special Publication 800-53.
As agencies go through the RMF development, testing, and reporting process, they prepare POAM(s) to spell out how they will correct security deficiencies that they find (called “weaknesses”), the resources that they will need to do so, and when the weakness will be corrected. Agencies use the POAM to also report their progress to the organization’s Authorizing Officer (AO) through automated tracking systems like Cyber Security Assessment and Management (CSAM) or Enterprise Mission Assurance Support Service (eMASS).
In plain(-er) language, a POAM is a detailed “to-do” list that organizations check off internally and hand over for someone else to check.
Under NIST guidance, an agency must prepare separate POAMs for each of their system controls that do not meet their prescribed RMF threat posture.
It is important to note that, though they are similar, there are distinctions between POAMs developed within the federal government (described within NIST Special Publication 800-115) and those that private-sector federal contractors must develop when they intend to handle government Controlled Unclassified Information (CUI) on non-federal systems. The private-sector-facing POAM guidance is described in NIST Special Publication 800-171.
Why Having a Complete POAM is Important
A thorough POAM is important for many reasons:
- As a reporting vehicle, POAMs give agencies’ Offices of Management and Budget. (OMB) access to cybersecurity compliance cost projections for budget planning.
- Managers track and become accountable for completion timelines.
- It makes security compliance a manageable exercise by breaking large challenges into smaller parts.
- An agency’s Office of the Inspector General (OIG) can review POAMs to readily evaluate security and privacy performance.
Everything that Needs to be Included in a POAM
NIST provides a POAM spreadsheet template with a standardized format, which must be customized to make them compatible with CSAM, eMASS, or other tracking systems. Typically, each federal department or agency has their own POAM template where they add columns to NIST’s standardized template as well, but they usually include NIST’s template columns at a minimum. The spreadsheet includes a header with general overview information – some of which may be separate columns for some organizations – and a minimum of eight columns: 1) Weakness; 2) Responsible Office/Organization; 3) Resource Estimate; 4) Scheduled Completion Date; 5) Milestones with Interim Completion Dates; 6) Changes to Milestones; 7) How was the Weakness Identified?; and 8) Status. Many POAMs also include columns for 9) Risk Adjustments and/or 10) Supporting Documents.
The following is a brief overview of what goes into each POAM section.
1. Header Information
The header includes spaces for the organization’s name, the name of the specific system the POAM applies to and its System Owner, and the latest update date. Finally, the header includes a statement of the system’s “Impact Level,” based upon Federal Information Processing Standards (FIPS) Publication 199. Some organizations call these “Risks” or “Risk Ratings.” Impact Levels are measured by the general effect of a system’s loss. “Low” impact levels correspond with minor inconvenience; “Moderate” impacts might bring some financial losses or temporary functional loss; “High” or “Critical” impacts could be life-threatening or they could catastrophically damage an organization’s system or multiple systems.
Some agencies may include space to provide a statement of a weakness’s visibility: how easily could someone outside of the organization find and/or exploit it.
The Impact and (if applicable) Visibility Levels help the organization and the reviewing agency prioritize the weaknesses effectively.
2. Areas of Non-Compliance, aka. “Weakness”
The first component of a POAM is a specific definition of each of a system’s controls that do not meet your agency mission’s specific goals and impact levels as defined in NIST SP 800-37 Rev. 2. Each weakness is given a unique identifier that typically links it back to its corresponding 800-53 control.
It is critical to focus on defining the root causes of a weakness and not just addressing the symptoms of it. These weaknesses can be limited to a specific system or they could be programmatic within your organization.
Examples of System Weaknesses: System audit records not exported correctly; System data improperly encrypted; weak passwords permitted on hardware; firmware out of date.
Examples of Program-Level Weaknesses: Failure to implement security training for new hires; not updating security policies in accordance with changing best practices.
3. Who is Overseeing Progress on Addressing the Deficiency? Aka. “Responsible Office/Organization”
We all know there’s a difference between hearing “Someone will take care of that for you” and “I will take care of that for you.” Tasks are more likely to be completed properly if someone is specifically responsible. Identify the person/role who is individually responsible for remediating the control weakness. Be sure to include their contact information.
There may be other column(s) to identify the individual(s) who are responsible for verifying that the CAP has been carried out and, most importantly, that the weakness has been remediated to an acceptable level.
4. Resources Needed to Solve Vulnerability; aka. “Resource Estimate”
In this space, provide an honest and realistic estimate of what it will actually cost to resolve the vulnerability. Costs could be financial – purchasing new equipment or hiring outside consultants – or they could be measured in staff hours. As with everything in the POAM, be specific in your estimate.
Some organizations report this information in a single column while others may break this data point up. For example, FedRAMP POAMs often have a separate column to specify outside vendor dependency versus internal resource requirements. Other organizations’ templates ask for a column strictly for the dollar value needed with a separate column for justification for that amount.
5. Corrective/Remediation Action Plan
Provide a high-level overview of the actions that must be taken to resolve the vulnerability as outlined in the Corrective Action Plan (CAP). You will break the overall remediation task up into smaller chunks in the following column.
6. Milestones with Interim Completion Dates
Use this column to lay out all of the subtasks and milestones that make up the overall corrective plan. In a high-quality POAM, each of these subtasks will be Specific, Measurable, Assignable, Realistic, and Time-Related: SMART. Include specific due dates for completing these interim tasks. If correction is a multi-step process, separate each step into its own line on the document. As you meet a milestone and complete that subtask, scratch it off your list, but don’t delete it. Furthermore, if you don’t meet a prescribed milestone due date, don’t change it here. Instead, record such changes – ideally with substantiated justification – in a separate “Changes to Milestones” column.
7. Scheduled Completion Date
Deadlines to remediate a weakness are based upon 1) the date the weakness was discovered – not the POAM’s date – and 2) their Impact Level: generally, “Critical” weaknesses must be completed in 15 days, “High” – 30 days; “Moderate” – 60-90 days; and “Low” up to 180 days. These aren’t universally codified deadlines, however. Different agencies may have different deadlines for completing all the tasks in a POAM.
8. How was the Weakness Identified?
Weaknesses can be discovered and/or brought to your attention through a range of vehicles. They can be found during internal vulnerability assessments like penetration tests or your system’s cybersecurity monitoring software; they can come from external parties like Government Accountability Office (GAO) or Inspector General (IG) assessments; or they can be found during an active breach event. In this space, specifically describe how this vulnerability was found/brought to your attention.
Some POAM templates include a separate column for the date the vulnerability was first detected because this date is the basis for your interim deliverable deadlines. In others, you can include it here.
9. Status
The last column in the standard POAM template is used to state at which stage the weakness/remediation is being reported. Here are a few of the most common statuses used in the template:
| Draft | The weakness has been identified but the specific assessment details and remediation approach are being reviewed. This status is automatically assigned during the first 30 days after someone identifies it. After 30 days, it must no longer be in “Draft” status. |
| Ongoing | Assigned when a weakness is actively being mitigated and work is still within its prescribed completion date. |
| Delayed | The weakness is actively being mitigated but the prescribed completion date has lapsed. |
| Pending Verification | This status code is used when the applicant has completed all of the remediation steps in the POAM but an outside party is verifying that they are sufficient to meet 800-115 compliance. |
| Completed | All of the remediation tasks have been completed and the source of the weakness has been adequately resolved. |
10. Risk Rating/Adjustment
These columns (where present) document the weakness’s system risk at the beginning and at the end of the process. In many instances the risk rating would be lowered by carrying out the CAP but it may not be eliminated entirely. Instead, the system owner determines that the risk has been lowered to an acceptable level and formally “accepts” it.
11. Supporting Documents
Many agency POAMs will include a column to list documents that would be relevant to the process such as evidence of remediation or justification for deviation from the original, approved CAP. When applicable, include actual filenames with each document.
Download the Free POAM Template
Don’t know where to start? Download your free POAM template here.
Automation – A Critical Tool for POAM Success
In the beginning, FISMA-mandated system cybersecurity audits followed an annual cycle. Since then, the size, complexity, intricacy, and prominence of these systems has steadily grown. Bearing in mind that FISMA prescribes separate POAMs for each security-deficient system, this proliferation has a dramatic impact on the sheer number of documents that are required. Even on an annual cycle, the burden of maintaining accurate and current POAM status tracking and reporting grew with the systems. In reality, monitoring and assessment frequencies increased as well to stay ahead of the rising security risks we face. The modern-day government information system must be regularly scanned and continuously monitored for weaknesses, making for an immense, but no-less-necessary challenge.
Not only is your POAM mandate substantially harder to manage without automation, more than likely it’s practically impossible! With the right automation systems in place, the POAM tracking challenge can be greatly reduced.
NIST specifically encourages organizations to employ automated systems in their POAM process. When compared to manual processes, automation tools work faster, are more thorough, and more accurate. They also more deftly support information gathering and coordination, giving leadership essential decision-making data in a timely manner.
In short, automation is a crucial component of the POAM process.
How IPKeys can Help with Meeting the Requirements
Vetted Tools
Private-sector solutions aren’t going to meet the rigors and unique cybersecurity challenges that a public agency faces. You need threat assessment and alert systems that were developed for the DoD to meet the steepest NIST security requirements for federal agencies. You also need to interpret the security data with analytics and dashboards that are both familiar to public agency representatives and customizable enough to meet your agency’s unique needs.
Experienced Team
The skilled specialists at IPKeys focus on cybersecurity that is tailored for government organizations. They developed their distinct suite of security tools and smart strategies for the DOD to meet their rigorous specifications. These same tools can keep your data safe and your systems running.
Automation and Reporting
Trust dedicated professionals and tools to accurately and exhaustively find vulnerabilities in your unique work environment and find the approaches that work best to address them. Use CLaaS to automatically generate POAMs, check for changes and update them as you fill in identified weaknesses, and report them for review in a format that works for your assessors.
POAM FAQs
How do I write a POAM?
So often, it’s the first step that’s the hardest to take, particularly if that first step has a ton of sub-steps built into it. There are a wide range of POAM templates available that you can fill out to formalize your POAM. Follow the brief summary above to see what information you need to provide in which columns and begin to tackle your cybersecurity weaknesses. This can be a daunting task, but it is one that is significantly more manageable with automation and AI-based software tools.
What is the purpose of a POAM?
A POAM is a standardized tracking and reporting document that breaks out all of the intermediate steps required to resolve and rectify cybersecurity weaknesses observed in an organization’s systems. Organizations use POAMs to prioritize which weaknesses to address first; to track progress on subtask milestones as well as on the overall effort; and to report their progress to management in a format that works with their infrastructure.
How do I use the POAM to prioritize corrective actions?
As you prepare your POAM, you must consult FIPS 199 to define its Impact Level: Low, Moderate, High, and (in some instances) Critical. While you may be inclined to address the Highest Impact vulnerabilities first – not a bad strategy, of course – you may find that some of your Low Impact vulnerabilities have a higher visibility and therefore are more likely to impact you if unaddressed. You should view all of your POAMs and their sub-tasks collectively and collaboratively within your organization to prioritize in a manner that works best for you.
What is the difference between an SSP and a POAM?
The System Security Plan (SSP) and Plan of Action and Milestones (POAM) are different because they serve two different purposes when it comes to managing risks and weaknesses on your information system. An SSP is a living, all-encompassing journal of the actions, changes, manuals, and protocols related to a system. It serves as a reference for security assessment and for future work planning. A POAM is a specific list of tasks that need to be completed to mitigate a weak security control.
To envision the relationship between the two, think of a productive Saturday at home. You pick up your honey-do list of backyard projects on the kitchen table (the POAM) and methodically mark items your spouse has requested off the list as you complete them. At the end of the day, your honey-do list is empty (if you know what’s good for you!). When your spouse comes home and asks, “What did you do today?” you respond with the domestic equivalent of an SSP. You rattle off that you 1) mowed the lawn – adding in that you had to gas up the mower and you ordered a new spark plug; 2) painted the fence – and you hand over a copy of the paint color chip for future touch-ups; and 3) looked up the serial numbers on the AC unit and finally filed them online with the manufacturer for warranty information and printed out the confirmation for the file cabinet.
The POAM gets smaller while the SSP gets longer.
Does every cybersecurity risk need to be corrected through a POAM?
No. According to the NIST guidance, in rare cases, the system owner can argue that the risk is acceptable to them and therefore it does not need to be corrected. If that risk posture is approved, it often comes with requirements to be reviewed annually thereafter to make sure that the underlying threat level isn’t greater than initially estimated.
