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.
SSPs in App Central¶
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.
Note
Tooltips provide explanatory text that guides you through form completion as you develop your SSP. An “i” enclosed in a circle represents a tooltip. Select this icon to gain additional insight.
SSP Sections¶
Page panels/sections include:
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 the Application Name, System Version, and Impact Level fields.
Authorization Boundary Diagram
This section requires you to provide your software components and data connections such that our team may understand your system design – ensuring proper connections to our environment. For example, we need to know your external data connections and similar components. You must complete a Game Warden-provided template for upload. For additional information, read Authorization Boundary Diagrams.
Role Identification
You must provide the names of government persons pertinent to your contract/application. Each grouping contains a tooltip which – upon selection – provides explanatory text about the roles you must identify. This section contains the Full Name, Title, Organization, Email, and Phone fields for the Government Authorizing Official, Government System Owner, Government Information System Security Manager, Government Contract Sponsor, Government Prime Contractor, Company Product Owner, and Company Security Manager.
Components
This section requires you to include or exclude components. The components you exclude will neither appear in your Deployment Passport SSP nor be deployed at this IL.
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).
Deployment 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.
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.
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.
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.
-
Click the
-
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
-
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.
Feedback
Was this article helpful? Want to see something more?
Please reach out to us here with your feedback.
Last Updated 05/23/24