The Power of the POAM
What is the best way to think about the POAM Lifecycle?
In Brief
Using the US Intelligence Community’s Intelligence Cycle as a guide to handle POAM’s from “cradle-to-grave” is one of the best approaches. The process here has been slightly modified to provide a more pertinent description for the purposes of POAM creation. We have found this model to be effective for the novice through professional cybersecurity or IT specialist…and it works well.
This includes the following abbreviated six stages:
- IDENTIFY: Those controls that time, technology or cost that cannot be met to satisfy the unimplemented security control.
- RESEARCH: You now have decided the control is not going to be met. The typical initial milestone is to “research” what it is and how to best address it over time. You will also need to identify the internal challenges the company or agency may face from a people, process, or technology perspective. Does it have to be solely a technical solution?
- RECOMMEND: At this phase, all research and analysis has been done, and presumably well-documented. Typically, the cybersecurity team or IT team will formulate recommended solutions for the System Owner, i.e., the business decision-makers such as the Chief Information or Operations Officer. The recommendations must not only be technically feasible, but cost and resources should be part of any recommendation.
- DECIDE: At this point, company decision-makers not only approve of the approach to correct the security shortfall but have agreed to resourcing requirements to authorize the expenditures of funds and efforts.
- IMPLEMENT: Finally, the solution is implemented, and the POAM is updated for closure. This should be reported to, for example, the System Owner, Authorizing Official (as part of the formal Authority to Operate process), Contract Office on a recurring basis.
- CONTINUAL IMPROVEMENT. Like any process, it should be regularly reviewed and updated specific to the needs and capabilities of the company or organization. This could include better templates, additional staffing, or more regular updates to management to ensure both a thorough and supportive understanding of how cybersecurity meets the needs and mission of the business.
The POAM Lifecycle
We begin in the “Identify” section of the lifecycle process. At this stage several things may occur. The business owner or IT staff recognizes that the security control is not or cannot be immediately met, or they employ automated security tools, such as ACAS® or Nessus®, that identifies securities vulnerabilities within the Information System. This could also include finding that default passwords, like “PASSWORD” have not been changed on internal switches or routers. It could also include the scans have discovered that updated security patching has not occurred; some automated systems will not only identify, but recommend courses of action to mitigate or fix a security finding. Always try to leverage these tools as soon as possible to secure an IT environment.
Mitigations must be based upon a strategy that is specific and addresses the risk. The risk may be broad such as widely known risks. Such risks may be found using open-source information threat sources and databases about nation-state actors. It can also be found using automated tools, for example, that identify weaknesses created by not applying security patches to an Operating System or application.
While the objective is to develop a well-written POAM, it should always be based upon a specific risk. Sometimes this may not be possible based upon, for example, the federal government’s restriction for sharing “classified” information about a certain risk or threat. The mitigation should be commensurate (and preferably, overwhelming) toward the threat. Mitigating approaches, for example, the technical addition of better malware tools, stronger physical security controls of a site, or even better training of personnel, should always be a consideration in formulating an interim solution (milestone) that reduces the threat, but recognize is may not necessarily eliminate it.
Furthermore, technical mitigations, such as security hardware or software additions, should be about reducing the attack surfaces, impacts, or likelihoods of a successful exploit attempt. These should never be relied upon in total, and should consider improvements in company or agency processes, procedures, and personnel practices.
Also, assumed in this stage is the act of documenting findings. The finding should be placed in a POAM template as the business or agency moves through the lifecycle. This could be done using documents created in Word®, for example, but the better recommendation is using a spreadsheet program that allows the easier filtering and management of the POAM. Spreadsheets afford greater flexibility during the “heavy lift” portion of formulating all POAM’s not intended to be fixed immediately. These may be because of technical shortfalls (“don’t have in-house technical expertise to setup Two Factor Authentication (2FA)”) or because of financial limitations (“the costs are currently prohibitive to implement the controls as required.”)
In the “research” phase this includes technical analyses, Internet searches, market research, etc., regarding viable solutions to address the security control not being “compliant.” This activity is typically part of initial milestone established in the POAM. It should be added in the POAM, and could be, for example: “Conduct an initial market research of candidate systems that can provide an affordable Two Factor Authentication (2FA) solution to meet security control 3.X.X.” Another example might be: “The cybersecurity section will identify at least two candidate Data at Rest (DAR) solutions to protect the company’s corporate and CUI data.” These initial efforts are a normal part of any initial milestones that clearly describe reasonable actions to address non-compliant controls.
Another part of any milestone establishment action is to identify when the milestone will be complete. Typically, milestones are done in increments of every 30-days. If the complexity of such an activity requires additional time, ensure the company has identified reasonable periods of times with actual dates of expected completion; never use undefined milestones such as “next version update” or “Calendar Year 2020 in Quarter 4.” Real dates are mandatory to truly manage findings supported by automated workflow or tracking applications of expiring or expired POAMs.
At the “recommendation” phase, this is the time when the prior research has resulted in at least one solution, be it additional skilled personnel (people), enhanced company policies that manage the security control better (process), or a device that solves the control in part or total (technology). This should be part of this phase and be included in the POAM template as a milestone with the EXPECTED completion date.
At the “decide” phase, company or agency decision-makers should approve a recommended solution. The decision should be documented in a configuration change tracking document, configuration management decision memorandum or in the POAM itself. This should include approved resources, but most importantly, any funding decision should be acted upon as quickly as possible. While many of these suggestions may seem basic, it is often overlooked to document the decision so future personnel and management can understand how the solution was determined.
The “implementation” phase may become the most difficult. It is where a lead should be designated to coordinate the specific activity to meet the control— it may not necessarily be a technical solution, and could be a documentation development activity that creates a process to manage the POAM.
Finally, ensure that as soon as the company or agency can satisfactorily implement its solution, close the control and notify the appropriate office to include, for example, the System Owner, Authorizing Official or Contract Office of the completion.
Typically, updates and notifications should occur at least once a quarter, but more often is appropriate for more highly impactful controls. For example, Two-factor authentication and automated auditing are best updated as quickly as possible. This not only secures the company’s network and IT environment, but builds confidence with the government, stakeholders, company leadership, etc., that security requirements are being met.
A final area to consider in terms of best-practices within cybersecurity, and more specifically in developing complete POAMs, is the area of continual improvement. Leveraging the legacy Intelligence Lifecycle process is a good model for IT and cybersecurity specialists to emulate. Everyone supporting this process should be prepared to make changes or modifications that better represent the state and readiness of the system with its listing of of still-to-be-completed POAMs.
Current Guide Available on Amazon:
Dr. Russo is currently the Senior Data Scientist with Cybersenetinel AI in Washington, DC. He is a former Senior Information Security Engineer within the Department of Defense’s (DOD) F-35 Joint Strike Fighter program. He has an extensive background in cybersecurity and is an expert in the Risk Management Framework (RMF) and DOD Instruction 8510, which implement RMF throughout the DOD and the federal government. He holds a Certified Information Systems Security Professional (CISSP) certification and a CISSP in information security architecture (ISSAP). He has a 2017 Chief Information Security Officer (CISO) certification from the National Defense University, Washington, DC. Dr. Russo retired from the US Army Reserves in 2012 as a Senior Intelligence Officer.
