Open gary-fallon opened 1 year ago
Per #50700.
LOE Medium
Problem Statement As a platform, we've never been super proactive with security governance. We had historically performed the privacy and security review when we had the resourcing to do so, but that leaves security to the last minute and then VFS teams sometimes have to perform extra cycles to account for our feedback, ultimately pushing out their expected launch date.
How might we create a process that improves security review and maintains architecture documentation so VA can meet the ATO requirements as new products/features are deployed?
User Impact All VFS and platform teams
Where was this problem reported? Thomas and Ray -- Security OCTODE lead
What do we not know about the problem space? Not much
What (if any) research or discovery has been done? None
What is the acceptance criteria? • System Architecture Document: This document provides an overview of the system components, data flows, security measures, and system design. o defines services within the authorization boundary; b. depicts all major components or groups within the boundary; o identifies all interconnected systems, including the Agency Access Point (e.g., VA.gov); o identifies data flows; anywhere Federal data is to be processed, stored, or transmitted; clearly delineate how data comes into and out of the system boundary; and depict how all ports, protocols, and services of all inbound and outbound traffic are represented and managed, including the use of definitive Agency DNS Ports, Protocols, and Services Template (PPS) o depicts all major software/virtual components (or groups of) within the boundary. o maintains the inventory of software and hardware All lower environment assets must also be inventoried for discovery purposes due to being connected to the VA network. • Security Architecture Document: This document outlines the system’s security measures, including access controls, threat mitigation, and security incident management.
How should we measure success? Evidence of continuous maintaining platform architecture documentation that meets ATO requirements as the platform or any hosted application changes. Scope • Establish a platform architecture management process: Set a platform architecture maintenance schedule (e.g., quarterly, semi-annually, collaboration cycle touch points) and the process for reviewing and updating the architecture documentation. • Assign roles and responsibilities: Designate a team or individual responsible for reviewing and maintaining the architecture documentation and ensure that they have the necessary resources and training to perform the task. • Review and update the architecture documentation: Regularly review the documentation to ensure that it accurately reflects the current state of the architecture. Update and version the documentation to reflect any changes to the platform or hosted applications. • Automate and standardize documentation updates: Utilize tools and automation scripts to reduce manual effort and improve accuracy in documenting changes. • Implement change management procedures: Implement change management procedures to ensure that all architecture changes to the platform or hosted applications are documented and reviewed for potential security implications. • Incorporate security reviews: Integrate security reviews into the platform and application architecture change management to identify and address any potential security vulnerabilities or risks. • Conduct periodic security audits: Regularly conduct security audits to validate the accuracy of the architecture documentation and identify any areas for improvement. • Foster a culture of security: Encourage all stakeholders to prioritize security and view the architecture documentation as an essential tool in maintaining a secure architecture.
Description
"Establishment of and charter for a group of qualified people with responsibility for the process of controlling and approving changes throughout the development and operational lifecycle of products and systems; may also be referred to as a change control board." -- https://csrc.nist.gov/glossary/term/configuration_control_board
Tasks
The following tasks must be reviewed and completed as necessary.
Acceptance
The following tasks must be completed before this issue can be considered done.