x

Agile Insider Blog

What is a POAM?

What Is a POAM?

Compliance with NIST 800-171 and DFARS requires two critical documents: The Plan of Action and Milestones (POAM or POA&M) and the System Security Plan (SSP). The SSP shows how a cloud service provider (CSP) meets security requirements. Further, the POAM shows how it will address and fix any known weaknesses. A CSO applying for a FedRAMP agency authority to operate (ATO) or JAP Provisional ATO must file a POAM.

The FedRAMP Template Completion Guide contains detailed information for creating and maintaining a POAM. This requires strict adherence to the template. It’s available as a downloadable Excel template.

Overview of the POAM

The POAM’s purpose is to make risk identification and mitigation for a cloud information system systematic. It identifies existing risks, ongoing monitoring, corrective actions, and current disposition. Then, FedRAMP reviews the POAM to establish the CSP’s current state in correcting the enumerated risks. The document needs to do the following:

  • Identify the security categorization (low, moderate, or high).
  • Enumerate weaknesses and deficiencies in security controls.
  • Evaluate the importance of weaknesses and deficiencies.
  • Describe the scope of each weakness as it relates to components in the environment.
  • Propose an approach to the mitigation of weaknesses and deficiencies.
  • Lastly, describe the current progress in mitigating them.

The CSP may discover weaknesses in its initial assessment, its periodic security control assessment, or its continuous monitoring process. Include all of them in the POAM.

The CSP will update the document periodically as it makes progress and submit updates monthly. It needs to identify specific milestones and give a schedule for achieving them. The template allows the creation of open items, which are changed to closed items when they are resolved.

While a CSP maintains a POAM as an Excel spreadsheet, the underlying data model is independent of any specific representation. There are formal models for representing it in XML, JSON, and YAML. Strict adherence to the structure is necessary so that processing software can handle it correctly.

Establishing the Security Categorization

The security impact levels of the information handled determine a system’s security categorization. The highest impact level governs. If the system has any high-impact functionality, its security categorization is “high.” The categorization affects what counts as an important weakness and how urgent mitigation is. It determines what cloud infrastructures provide acceptable security.

The levels are based on FIPS 199. A categorization of “low” means that a breach will have only a limited adverse effect, causing inconvenience but no major harm to the provider or anyone else. An example of this would be a system that provides only public data, where its temporary loss isn’t critical.

A “moderate” categorization signifies potentially serious harm from the loss of data availability, confidentiality, or integrity. The harm might include significant financial loss and personal but not life-threatening harm to individuals. A system that handles personal financial data would be an example.

A “high” categorization says that a breach could cause serious or catastrophic harm. The potential for major damage to financial assets and danger to human life would fall under high-impact risk. A power grid or a secret military research facility would have a high impact level.

A CSP that achieves the moderate and high levels has access to more contracts. At the same time, the failure to live up to those levels has more serious consequences. A provider that seeks contracts at these levels needs to have solid practices, and its SSP and POAM have to reflect this.

Preparing the Document

The template, which is partly based on NIST formats, is not optional. The CSP may not delete or alter any of its columns and headers. Then, add fields as necessary for internal and FedRAMP requirements.

There are two worksheets, one for open items and one for closed items. Each worksheet starts with a Header Information Description, which provides general information about the system:

  • Vendor name
  • System name
  • Impact level
  • Lastly, the date of the last update

The remainder of each worksheet consists of the open (for the first worksheet) or closed (for the second) items. A full description is in the Template Completion Guide. Highlights include the following:

  • Unique identifier
  • Description of the weakness
  • FedRAMP security control affected
  • Risk rating
  • The person responsible for managing the item
  • Dependencies
  • Milestones
  • Supporting documents
  • Lastly, relevant dates

Open items include three categories of vulnerabilities. They are ones identified through vulnerability scanning tools, ones identified by other means (e.g., penetration testing), and ones where the CSP is submitting a deviation request. Following FedRAMP’s strict requirements for vulnerability scans and penetration tests is essential.

Items may be moved from the open-items worksheet to the closed-items one when mitigation is complete or when the item is declared a false positive. A third party assessment organization (3PAO) must verify the mitigation. Risk adjustments and false-positive designations require filing a deviation request form before entering them in the POAM.

A CSP must maintain an inventory workbook, which has its own template. Have a separate document or add it to the POAM worksheet.

The Lifecycle of a POAM Item

What is a POAM?

As already noted, a weakness can be initially identified in several ways. The use of vulnerability scan tools is the most common, and these weaknesses are generally easy to mitigate. CSPs must scan web applications, databases, and operating systems monthly. Scanning tools need to follow FedRAMP requirements. They need to use CVE reference numbers and CVSS scores when available. The output of a scanning tool needs to be in a structured data format, such as XML, JSON, or CSV.

One vulnerability may turn into multiple POAM items, if separate mitigations are necessary for different assets. However, multiple vulnerabilities should never be grouped into one POAM item.

Penetration testing is valuable for finding weaknesses that aren’t already categorized or result from configuration issues. It involves a wide variety of approaches, but FedRAMP provides a guidance document. Pen testing in this context includes not only probing software for weak points but simulated phishing.

An identified weakness will be entered as an open item, recording how and when it was identified. It will be assigned a point of contact. An overall remediation plan and one or more milestones have to be added promptly.

Mitigation can be as simple as downloading a patch or fixing a configuration parameter. In other cases, research may be necessary to find the source, and developers may have to write a new code. Whatever the remediation steps are, their execution has to be kept in sync with the POAM, so it reflects the current status from month to month.

CSP

If a patch is available from a vendor, the CSP has to apply it within a time limit. It has 30 days from the date of availability to fix high-risk rating vulnerabilities, 90 days for moderate ones, and 180 days for ones rated low. If there is no dependency on a vendor patch, these deadlines apply from the date of identification.

Once the remediation of an item is complete, the CSP has to document it and have a 3PAO verify it. It moves the item to the Closed worksheet after completion.

Sometimes there is no way to fix a weakness without impacting the operations of a system. The CSP can file a deviation request for an operational requirement (OR). If the risk is low. For instance, if its functionality is not enabled, leaving the weakness in place may be acceptable. Whether the request is approved or not, the item remains in the open items worksheet. The CSP needs to periodically review any approved ORs.

CMMC and POAM

There is some confusion on how FedRAMP requirements, including POAM, relate to Cybersecurity Maturity Model Certification (CMMC). CMMC certification is for businesses looking for DoD contracts, while FedRAMP is for CSPs seeking all types of US government contracts. Work is underway for reciprocity between the two types of certification so that contractors don’t have to take the same steps twice. Getting one certification is a stepping stone toward the other.

The idea of acknowledging and tracking weaknesses doesn’t have a direct counterpart in CMMC, and some have expressed doubt about whether POAMs can coexist with CMMC certifications. The best way to look at it is that POAMs cannot include open items that are required to attain the desired CMMC level. It can include items relevant to its FedRAMP security categorization, but not required for CMMC certification level. Fixing them could be a step toward a higher CMMC level later on.

Agile IT Can Help

Federal security certifications require a major investment of time and effort. However, expert assistance makes the process faster and less stressful.

Agile IT is one of only ten Microsoft Partners who are approved to license, migrate, and manage GCC High for DoD Contractors. In fact, we have migrated over 2,000,000 accounts to the cloud for nearly 2,000 organizations, and we hold over 15 Microsoft Gold Competencies. If you are looking to get ahead of your organization’s CMMC requirements, request a free consultation today.

Leave a comment

Learn More Today

Have questions or want to learn more about the services and solutions Agile IT has to offer?

Schedule a call with us today!

Schedule a Call
or

Request a Quote