Skip to content

Significant Software Changes and Authorization Requirements in Game Warden

The Department of Defense (DoD) utilizes Game Warden, a Platform as a Service (PaaS) solution, to streamline cloud-hosted application development, deployment, and operations. Understanding how software changes within the Game Warden environment impact security and authorization is crucial. Game Warden defines significant software changes for applications and outlines when a new deployment passport (DP) is necessary based on deltas in a given cyber risk posture.

Defining Significant Changes

Any significant change to your application will trigger a new security review, Deployment Passport, and Certificate to Field (CtF).

A significant software change in a Game Warden-hosted application refers to any modification that could:

  • Alter the Security Posture: Introduce new vulnerabilities, change data flows, add new user populations, or expose new attack surfaces within the Game Warden environment.

  • Materially Increase Cyber Risk: Expand the potential for unauthorized access, data breaches, or service disruptions specific to the Game Warden platform.

Game Warden Considerations

  • Shared Responsibility Model: Game Warden manages the security of the underlying Game Warden infrastructure and platform.

  • Built-in Security Features: Game Warden incorporates various security features, such as continuous monitoring, automated security testing, and vulnerability scanning. Significant changes may require re-evaluation to ensure continued compliance with the terms of the authorization to operate.

  • Compliance Requirements: Game Warden faciliitates compliance with DoD security standards. Significant changes may require re-evaluation to ensure contineued compliance with the terms of hte authorization to operate.

Examples of Significant Changes

  • Modifying Core Application Logic: Changes to the primary functionality or workflow of the application hosted on Game Warden.
  • Altering Data Handling: Changing how sensitive data is stored, accessed, or processed within the Game Warden environment.
  • Integrating New Services or APIs: Adding new third-party integrations within Game Warden that could expose data or introduce new vulnerabilities.
  • Customizing Security Configurations: Modifying firewall rules, access controls, or encryption settings within the Game Warden platform.
  • Leveraging New Game Warden Features: Utilizing newly released Game Warden features that significantly alter the application's behavior or capabilities.

Routine Updates vs. Significant Changes in Game Warden

Feature Routine Update Significant Change
Scope of Change Minor code adjustments, configuration tweaks, or content updates within the Game Warden environment. Changes to core application logic, data handling, or integration with external services on Game Warden.
Security Impact Minimal impact on the security posture or risk exposure of the Game Warden application. Likely to introduce new vulnerabilities, alter data flows, or change the overall attack surface.
Authorization Typically covered under the existing authorization and do not require a new review by the AO. Requires a new authorization from the AO to ensure the modified software meets security standards.
Examples Deploying new versions of the application with bug fixes, updating configuration files, or adding like content within Game Warden. Implementing a new feature, integrating with a new API, or changing data storage mechanisms on Game Warden.

There are new change management requirements that necessitate a formal Security Impact Analysis be completed and signed off by the government. Depending on the impact of the change, approval authority will be our DIU Information Systems Security Manager (ISSM), the Government Security Controls Assessor (SCA), or the Authorizing Official (AO) himself for significant changes. Changes are assessed as Levels 1-3, with Level 3 changes functionally, meaning a new ATO process.

  1. Changes to GW, including our pipelines, IaC, SaC, and processes to yield deployment passports must be carefully evaluated before making the change. The Security Champions in the Product teams are the best way to ensure that proposed changes are correctly managed.

  2. Level 1 changes are described as

    • SW/firmware version updates that do not have security implications (including supply chain risk management security implications) but affect security controls associated with the current authorization and security baseline (e.g., releases and/or SW/firmware updates that add functionality, registry or permissions changes, adding additional pre-existing system assets)."
    • Level 1 changes which have an impact on container versions (semantic versioning) must be tracked for changes and approved by the Government ISSM.

  3. Level 2 changes are described as

    • Level 2 “Moderate”: A baseline change to a current authorization for an IS undergoing lifecycle upgrades and/or incorporating moderate changes to the IS that do not fall within Level 1 change types. These changes affect operation of the system and require ISSM and SCA determination. A Level 2 change must use the approved SIA template detailing the change and the analysis performed that determined the overall impact to the security baseline of the system.Changing the source of software updates or container images. (e.g., using an open-source repository instead of Iron Bank)
    • Adding or removing HW, SW, or other IT that is not within the same configuration of existing devices, SW, etc.
    • Changing the source of software updates or container images. (e.g., using an open-source repository instead of Iron Bank)
    • Introduction of new technologies not listed above, PPS, HW/SW/services not in the approved ATO baseline, technical capabilities, or functions that enable new missions, enhanced features, or operational environments, requiring the application of new STIG, scans, and/or other configuration type guides to support a hardened IS and environment.

  4. Level 3 changes are described as

    • ”Changes that require re-authorization. These are significant changes that can include an update to a currently authorized baseline that adversely affects the security baseline or a change that is so significant in size and scope that re-assessing risk on a subset of the system would not adequately or accurately reflect current security baseline and risk. All instances will be evaluated by the A&A stakeholders, and Level 3 determinations will be made on a case-by-case basis.”
    • Ex: “Technology refresh encompassing the addition or removal of multiple HW, SW, firmware, processes, or other IT components that are not within the same configuration of existing baseline.”