I recently read yet another call to action for improving the Authorization to Operate (ATO) process. The author appeared to have experienced the months or years it can take to prove the security of a single system or technology in the federal government – doing this for one client and then again for another and another.
While I don’t agree with all the points made in the article, I found it refreshing that the author didn’t just vent about their frustrations but used the piece as an opportunity to propose a solution — a Federal Compliance Library. Having spent my career on both sides of the compliance conundrum, I tried to think of how a Federal Compliance Library would work within government and industry.
The author points out that component redundancy and duplication of effort are at the root of the ATO problem. That is certainly a true statement, highlighting the unfortunate reality that the public and private sectors face when it comes to substantiating system security. A situation where, in most cases, one federal agency can’t use the same technology as another agency without going through a lengthy security assessment process that the technology already underwent at another agency. At first glance, this would appear ridiculous, but if we dig a little deeper into the problem and ask “why,” we may reveal the cause of this issue.
Without getting too technical, I suggest that compliance associated with secure configuration baselines and risk management are two related but very different processes. The NIST Risk Management Framework (RMF) is the process by which you strive to achieve that precious three-year ATO (if you are lucky). The process does not mandate full compliance, only compliance or security that will return a digestible or acceptable level of risk for the organization procuring the technology. With each consuming organization having varying missions and risk tolerances, adopting a plug-and-play compliance library is challenging but not impossible.
I like the idea of a compliance library or a library for secure baselines and best practices. However, for a compliance library to work, we need the agencies to have robust security programs that can adopt agile solutions into their existing security operations programs. Sadly, many organizations still do not have this. One could argue they don’t due to the number of resources they need to dedicate to compliance.
Additionally, because many organizations do not have a sophisticated inheritance model established, they must include an entire suite of security controls into their authorization boundary. When it comes to DevSecOps, many of these controls go well beyond the developers’ knowledge or authority. Being the problem solvers that developers are, they try their best to offer control implementation statements that sometimes contradict the organization’s security program, resulting in a flag by the auditor and a returned package.
Nevertheless, the concept of an approved-products list has been around for years. Last I checked, the DoD still has an approved-products list. The challenge with pre-approving operating systems, switches, routers, and similar technologies is that they still need to be configured and physically secured by certified professionals. Each organization’s unique usage of those technologies is where context is added and risk-based decisions are made.
There is hope for the development community through NIST’s Open Security Controls Assessment Language (OSCAL), one of the more mature compliance-as-code initiatives. With OSCAL, developers can write implementation statements within their purview and further compliance automation and reciprocity. Last year I attended two DoD conferences with dedicated tracks on ATO improvement. DoD realizes that when the CIOs of our armed services are distracted by ATOs instead of focusing on IT modernization for our troops, there is a problem! As the author of the article mentioned, we need to think differently and collaborate with each other. There are many problems to solve and solutions to propose, and all ideas should be welcomed and evaluated.