Using Innovative Documentation-as-Code Approach for the Georgia Department of Human Services System Security Plan

The state of Georgia had launched a large-scale digital transformation in 2020, and the migration of on-premises applications to the cloud required updated SSPs. One such application was DHS’s Document Imaging System (DIS), which converts paper records to electronic files. DHS had used more than 30 AWS services to build the architecture for DIS, which went live in April 2022 and features a user-friendly workflow to document and track security controls. For example, its logging and monitoring layer relies upon Amazon CloudWatch, which collects and visualizes near-real-time logs, metrics, and event data in automated dashboards to streamline infrastructure and application maintenance.

DIS uses AWS CloudTrail to monitor and record account activity across the AWS infrastructure, giving organizations control over storage, analysis, and remediation actions. It also monitors the security of the overall architecture using AWS Config, which continually assesses, audits, and evaluates the configurations and relationships of an organization’s resources on AWS, on premises, and on other clouds.

A special publication by the National Institute of Standards and Technology (NIST), NIST SP 800-171, details the complex requirements for handling CUI, including the mandate that organizations provide an SSP to show how they are complying. “Sometimes a federal partner provides you with a template that’s a locked document or spreadsheet, and you have to find ways to share that document or move it around to get the inputs that you need,” says Shirlan Johnson, DHS’s chief information security officer. “Writing these collaborative documents can be quite a daunting activity.”

In July 2022, DHS hired a new assistant deputy commissioner, Christopher Apsey, who recognized the cloud migration initiative as an opportunity to change how DHS generates SSPs. Apsey suggested that the agency implement an innovative strategy that he had developed while in the US Army’s Cyber Center of Excellence. “The underlying thought was rather than email a Word document back and forth, like how most documents are written in a business setting, let’s instead apply software development methods,” Apsey says. “It did change the scope of the project, and we hadn’t planned for it. The team, led by Rajeev Shirguppi as the ProServe Engagement Manager, were eager and willing to try something different."

In late 2022, the DHS security team, the DIS application team, and AWS Professional Services began working on the SSP using the new methodology. The teams had just 16 weeks to create the SSP because DIS had already been deployed to the cloud. “AWS Professional Services was instrumental in helping the SSP writers,” says Apsey. “They were very involved in technical debugging at the onset, so we could make the process as seamless as possible.”

Together, DHS and AWS Professional Services carefully reviewed each of the 110 controls within 14 control families—such as access control and incident response—detailed in NIST 800-171. The teams mapped each requirement to the DIS architecture built on AWS. To write the SSP, the teams used a markup language called AsciiDoc, a plain-text, lightweight writing tool that translates to many different desired output formats. They posted the AsciiDoc text in GitLab, an open-source code repository for DevOps projects. DHS created a user interface that presents the SSP in a web format for nontechnical users. “This innovative approach is similar to version control in software development, in terms of the speed at which code is normally developed and changes are documented and tracked,” says Johnson. “If we can bring this approach into the SSP world, we will improve how quickly things can be updated and tracked by orders of magnitude compared with the traditional way it’s been done.”

To update and change the SSP, DHS uses GitLab workflow, a development strategy that uses branches to make changes instead of working in the core document. Only authorized personnel can write, review, or approve changes. “Because it’s a security document, audit trails are important,” says Apsey. “The document updates dynamically as changes are made. You can see who made a change, why they made it, when it was made, and everyone who approved the change inherently in the protocol.” As part of the documentation-as-code project, the team collaborated on 118 issues and 37 merge requests in the GitLab repository for the SSP document to provide revision history and tracking. “An SSP is a living document,” says Johnson. “There is that initial uplift of creating it, but that is not the final destination. It has to be continually updated for the life cycle of the particular system that the document represents.”