Creating a System Security Plan (SSP) in an open and transparent manner can help to improve process quality while increasing communication and collaboration between different parts of an organization and even across orgaanizations. A proposed library of reusable compliance components enables wide review than can uncover existing but previouslly missed security vulnerabilities, and real-time support to manage the continuously evolving threat landscape.

Obtaining an ATO is required for every internet-based system in the federal government. The documentation for an ATO is called a system security plan or SSP. Creating the SSP can take months, and very few SSPs are clear, complete or well written. In particular, details about how, say, access control or audit logs are managed may be broadly covered with few specifics regarding the system at hand. Further complicating the process, is a shroud of secrecy that forces every ISSO building a SSP has to reinvent the wheel for every technology component that their system is using.

After inspecting hundreds of SSPs, we have found that the information contained within rarely requires secrecy to maintain the security of the system. And when such sensitive information exists it is usually misplaced and should not be in the SSP to begin with. To be clear, the results of assessing an SSP, that may include a list of discovered vulnerabilities, can reasonably be considered sensitive and maintained in a secure fashion. But there’s a little reason for the SSP itself to remain secret, or even for the secure management of the general component-level assessment processes. (Tailored, specific assessment processes aimed at a particular implementation and environment may be crafted to exercise specific features of a system, and therefore may have a need to remain secret. But this is the exception and not the rule.)

The threat landscape is evolving along with Moore’s Law at an exponential rate. Humans do not evolve so quickly. And there is an increasing need to be proactive in the expanding open source software world. SBOM can show you CVEs that exist, but you need to know, your developers need to know what the risks are and what needs to be protected and what the business case is. Where open source development appears to be getting more opaque, we believe this is the perfect time to introduce open source assessment and open source ATOs.