System Security Plans

A System Security Plan proves you meet Game Warden's Authority To Operate (ATO) security requirements and is instrumental in obtaining your Certificate to Field. You create the SSP from a template form inside the Game Warden app. The SSP includes required external approvals and proof of an active government contract for your company. The Game Warden Security team reviews this form and it is used as part of your Deployment Passport.

Creating an SSP

The System Security Plans (SSP) section off App Central allows you to to create new SSPs as well as view and edit any existing SSPs. To view or edit an existing SSP, click the corresponding block. To create a new SSP, click the + ADD SSP button.

All SSPs are specific to Production (PRD) environments and align with the Impact Level you designate. You must create an SSP for each Impact Level to which you intend to deploy your application.

SSP Sections

Left-Side Navigation A left-side navigation column organizes all the sections of the form. Click on any section title in the column to jump directly to that part of the form, making it easier to navigate and manage your progress.

Section Status Indicators Each section shows a "Complete" or "Incomplete" status. This helps you quickly identify which sections are finished and which ones are still pending before submitting the form for security review.

Edit & Save Your Progress Click the pencil icon next to a section to start editing. Be sure to click 'Save' after making changes to store your progress and prevent data loss. You can return to the form at any time to continue where you left off.

AI Attestation

You are required to complete this form, regardless of whether artificial intelligence is used in your application. If AI is not being used, simply select "No" when prompted. If AI is being used, the form will guide you through additional questions based on your responses to help the authorizing official assess the associated security risks.

Authorization Boundary Diagram

In this section, you must provide a clear and detailed Authorization Boundary Diagram. This diagram helps our team understand your system’s architecture, including software components and data connections, to ensure proper integration with our environment.

Additionally, under 'External Data Connections,' you will need to add any and all relevant connections. This will prompt you to answer a few related questions for each connection added."

For additional information and 2F approved Authorization Boundary Diagram templates, read Authorization Boundary Diagrams.

Business Continuity

You must provide at least two emergency contacts who may be notified if there are events, such as outages. This section contains the Full Name, Title, Email, and Phone fields.

CAC Personnel

For access to your endpoint and logs in an IL4 or higher environment, your team will need to have approved Government Access Cards. List these team members in this section.

Components

When submitting components (or services) for security review and authorization, you must select the version of each component you want to have deployed. If you do not wish to submit a particular component for review, select "Exclude" from the dropdown menu.

The version must be selected for any component you intend to have deployed at that Impact Level that you are submitting for authorization.

Deployment Basics

This section allows you to include an abbreviated Application Name or alias. The Application Name might be a shortened name that you use for a specific IL. For example, your Application Name might be Bossy Apps, but the abbreviated name or alias for IL4 might be Boss.

This section includes:

• Application short name
• System version number
• Deployment Sites/ Information Level

Deployment Information

In this section, please provide details about your application’s deployment, including the programming languages you use, any dependencies your app relies on, and other relevant information.

You must add information relative to government access cards and contract details along with insight into your application and external systems. For example, you must provide the names of all system personnel with a government access card, such as a Common Access Card (CAC), External Certification Authority (ECA), or a Personal Identity Verification (PIV) card. For additional information, read Government Access Cards. You must include the Full Name, Title, DoD Number, and Expiration Date. You also must list Government Contract details along with Application Programming Languages, Dependencies, Databases, and External Systems.

Information Security

You must provide information that helps our team understand your application security levels, such as Confidentiality, Integrity, and Availability. This section also includes the Distribution Control Type and Controlled Unclassified Information drop-down list boxes. You can provide applicable Security Classification Guide information along with insight specific to Personally Identifiable Information (PII).

Role Identification

You must provide the names of the government officials relevant to your contract/application, including the Government System Owner, Government Contract Sponsor, Government Prime Contractor, Company Product Owner, and Company Security Manager.

Technical Artifacts

This section is where you can upload the final versions of your technical artifacts to include in your Deployment Passport.

Creating a New System Security Plan

Follow the below steps to create new System Security Plans.

1. In the deployments section click on the "Add SSP" button next to the deployment you wish to create an SSP for.

2. This opens the Create SSP modal.

   

   • You must select an Impact Level
   • The Duplicate Existing SSP option allows you to import data from previously compiled SSPs into a new one, saving you the time to enter the same information
     • You will be prompted to select which SSP you'd like to duplicate
     • Do not set this option to Yes if creating an entirely new SSP

3. A new page opens, displaying the panels described above. You must click Fill Out Form to begin content entry, selecting Save to store changes.

   • As you add content to develop each SSP, the panel headers turn green – indicating panel or section completion. You can click Fill Out Form, should you need to edit content. Delete SSP, as its name implies, allows you to remove all file content. You might use this feature if, for example, you discover that you no longer need to deploy to IL4.

Note

Future automation includes validation checks that ensure SSP content accuracy. For example, there will be checks to ensure you do not include Controlled Unclassified Information (CUI) in IL2 SSP documents.

SSP Updating Best Practice

As the softwared development lifecycle is iterative and numerous changes are made to your application's containers, we recommend verifying the information in your SSP at least monthly.

FAQ

Is a new System Security Plan (SSP) needed for each version/update in Production (PRD)?

An updated System Security Plan (SSP) will be needed for each version which will be part of the deployment passport for that version. Though most fields will not change, things like Authority to Operate (ATO) status and assessment date will be different for each version.

What specific information does Game Warden need from my DOD contracts to meet the Authority to Operate (ATO) validation requirement?

Please upload the entire active contract and enter the contract number into your System Security Plan (SSP). We primarily look at the first page for validity of relationship between you and the DoD. We also need to verify the expiration date (Period of Performance) as well as a line item that specifies the mission application.
You cannot move your initial deployment into Staging (STG) until this is received in full, as it is part of your Deployment Passport.

Do I need to fill out a new System Security Plan (SSP) for each government customer I onboard?

No, you can select one current customer that supports your app's deployment at your target Impact Level (IL) to include in the System Security Plan (SSP). However, if the government customer you select stops working with your app, you will need to update the SSP to ensure it references a current customer.

In the System Security Plan (SSP), what is the difference between Government Customer and Government Sponsor, and why do we need them for Game Warden?

Government Sponsor can be any government organization that has provided a requirement you’re filling (ex: AFWERX, 16th Air Force). We recommend choosing your largest contract holder; one that is going to be around longest. In this case, you do not have to continually update your SSP. You can also include multiple sponsors.
Government Customer should be one of your customers that you are targeting with this deployment and match the Impact Level (IL) target. So, if you have a customers who needs IL-4, you can use them on the SSP for a target deployment to IL-4. If aiming for IL-6, put down a customer that needs IL-6; this will cover all lower ILs as well.

How do I determine the classification level of my app?

Your mission sponsor/government customers should be able to confirm for you what classification level of information your app will be storing or processing.

Last Updated 12/10/24

Return to Help Center Home