HOME       BLOG      CONTACT

 

shutterstock_184473665.jpg

Summit 7 Team Blogs

What is an SSP and POA&M? What's the Difference?

When we first talk with any business about Office 365 and Azure Government (not just organizations implementing NIST 800-171), one of the questions we ask is if they have a security plan or risk mitigation plan. It is a good practice for most any business to have both, a System Security Plan (SSP) and a Plan of Action and Milestones (POA&M). For NIST 800-171 compliance, it is a must.

Excerpt from NIST 800-171 

Nonfederal organizations should describe in a system security plan, how the specified security requirements are met or how organizations plan to meet the requirements. The plan describes the system boundary; the operational environment; how the security requirements are implemented; and the relationships with or connections to other systems. Nonfederal organizations should develop plans of action that describe how any unimplemented security requirements will be met and how any planned mitigations will be implemented. Organizations can document the system security plan and plan of action as separate or combined documents and in any chosen format. 

When requested, the system security plan and any associated plans of action for any planned implementations or mitigations should be submitted to the responsible federal agency/contracting officer to demonstrate the nonfederal organization’s implementation or planned implementation of the security requirements. 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 or not it is advisable to pursue an agreement or contract with the nonfederal organization. 

My PostSystem Security Plan

For starters, a System Security Plan (SSP) is an iterative document meant for updates as the company changes anything substantive about its security posture. Much like a well-kept Wikipedia page, every major update or remediation needs to be recorded and reviewed by other individuals. Information like network diagrams, administration roles, company policies, and security responsibilities by employee type are important for a complete SSP.

For the purposes of NIST 800-171 and CUI requirements, the SSP includes the necessary information about each system in your environment that processes, stores, and transmits CUI. This information includes security configurations or capabilities that are currently, or intended to be, implemented, and each capability is expressly tied to specific security requirements and controls. Furthermore, the SSP defines how each of these systems interact between one another (flow of information and shared authentication/authorization), as well as how they behave separately.

Plan of Action and Milestones

If the SSP is the collective details of a business' security posture and system(s) profile, the POA&M is the honey-do list. Each company's POA&M is likely different because it includes information about weaknesses and gaps according to NIST 800-171 standards, as well as the risk posture for each respective gap and any mitigating steps the company intends to make. We often suggest similar entries into each of our clients' POA&M's; however, not every company will decide to address every risk in the same way. After all, these are business decisions with operational and financial implications.


Bottom line: you have to possess a complete SSP and POA&M in order to conduct work for the Federal Government. A "complete" SSP is a working and living document, and a "complete" POA&M really is an empty document once you configure Office 365 and your other systems properly. As time goes on, your SSP will become larger in size to include more details about your environment and implementations. Conversely the POA&M should become a much smaller document as you check items off, take action, and reach milestones. Below is a graphical representation of this.

sspVpoam_2

Of course, once a system is added to your environment or a major system change is made, new things can be added to your POA&M to accommodate those changes. These milestones are likely to be few and far between, nevertheless.

Steps to Take

Digest NIST 800-171, and have as many as you can in your organization or leadership read it as well. You will inevitably need to conduct an internal audit of your organization and current security postures per each control family. That introspective look will require several different individuals in your organization if you have them: IT, operations, human resources, and security (FSO). Smaller businesses may only include one or two people, but the importance should be placed on multiple perspectives. For both of these documents (SSP and POA&M), you will likely find it difficult to task one individual that it truly cognizant of all processes and systems involved in the 110 controls. Nor will one individual be able to remedy any and all gaps found along the way.

As you go along, document as much as you can. You can start by grabbing one of the many templates available to you on the web by doing some simple searching. You have to start somewhere, and jotting down information and having a central document to drop data into is key.

Eventually, you might need to outsource some of this activity. It can be taxing on a team to completely assess their own business when they have never conducted a NIST review or audit. There is also the very human flaw we all have where we often do not observe our own blemishes as keenly as an outsider may. In summary, a third party may more speedily and accurately assess your business. You will also walk away with a much better looking and sound SSP and POA&M.

Some businesses we typically recommend for SSP and POA&M creation:

MAD Security SSP POA&M     

   Sentar SSP POA&MRB_H2L_Solutions_FullColor_v1[1]    H2L SSP POA&M

 

IF YOU HAVE ITAR DATA:

TCEngine SSP POA&M

 

 

SHARE THIS STORY | |
About