Government agencies are not known for moving quickly, and Risk Management Framework (RMF) accreditation is a prime example.
The Department of Defense (DOD) introduced the RMF in 2014 to help federal agencies better manage risks associated with operating information systems. Systems must be hardened to Security Technical Implementation Guide (STIG) benchmarks that provide configuration specifications for operating systems, database management systems, web servers, and network devices used by government agencies.
STIGs are long and detailed, often containing hundreds of pages. Adhering to or upgrading software or systems to a STIG has been a highly specialized manual process that can take weeks for well-trained engineers skilled in the technical system, operating system policies, and security guidance to accomplish.
Without this step, projects cannot move to authorization to operate (ATO). For defense contractors and integrators tasked with developing new technologies for the DOD and other government agencies, this step can take a year or more and delay deployment of new defense technologies.
New automated software tools are eliminating weeks, if not months, from the RMF accreditation process by eliminating initial hardening time while providing required documentation. Technology integrators can significantly reduce the time to build, test, and deploy new technologies in STIG-compliant environments.
Brian Hajost, president of automated STIG compliance company SteelCloud, says there are many misconceptions surrounding system hardening.
Few applications have specified STIGs. One example is Microsoft Word, which must be hardened when used in secure environments. Instead, most STIGs apply to the application stack that includes the operating system (Windows, Linux), web browsers, databases, and other components required for the application to function.
When an application is implemented in a STIG-hardened environment (changes made to the underlying operating system, for example), it inevitably runs into conflicts that can cause the application to break.
“Most applications are typically developed and tested in non-STIG environments,” Hajost explains. “So, when they are implemented in a hardened environment, they can break. These failures are unique to each application stack and sorting them out can take weeks or months for each application.”
So, RMF accreditation requires hardening the system and providing significant hardening documentation and details of all CAT 1/2/3 controls – a categorization of the degree of security risk.
These three levels represent the risk severity for failing to address a particular weakness – Category 1 represents a vulnerability that could directly and immediately result in loss of confidentiality, availability, or integrity; Category 2 represents more of a potential for loss; and Category 3 vulnerabilities degrade measures that protect against loss.
Automating the process
Vulnerability scanning software is available that can compare generic STIG signatures to identify controls. This highlights problem areas but does not resolve issues.
Scripting automation tools can be used but are expensive and not purpose-built for STIG compliance or accreditation. Because they do not produce documentation, these tools often must be used with vulnerability scanning software.
Even using both, these options do not make changes to controls that are specific to the application stack involved. More complete solutions now exist that include automated remediation.
ConfigOS from SteelCloud hardens all CAT levels (1/2/3) in about an hour, including producing a domain-independent XML signature and waiver documentation, eliminating weeks of manual work.
Once developed, the encrypted XML signature can be securely used across the DOD in all networks and domains without changes to existing security or infrastructure. The signature can be included with applications as they are transferred to disparate infrastructures from one mission partner to another.
The signature allows scanning, remediation, and compliance reports in about a minute. Because STIGs are updated every 90 days, the software also simplifies updating systems in production.
Many large defense contractors and agencies within the DOD and Department of Homeland Security have licensed the software.
“You basically have to mold these controls, and there are hundreds of them, around your application stack,” Hajost says. “Essentially you have to figure out what will break the application and correct the control – and software can automate that process.”
Hajost says the DOD will not authorize an ATO for systems with an unmitigated CAT 1 vulnerability except under extreme and rare circumstances. This can mean sending a project back into development to address the issue.
“Now a fix that would have cost $500 in the initial development can cost the government many thousands of dollars,” making it important to address STIG hardening as early in the DevOps process as possible, even before accreditation, Hajost says. “We estimate CAT 1s cost the government and the DOD thousands of dollars, per application, per year to maintain.”
CAT 2 and CAT 3 controls must also be hardened, or – if there is a reason the risk might not apply – users can request waivers that must be reviewed by accrediting authorities.
“We have seen examples where developers have said, ‘We’re just going to waiver all the CAT 3s because we don’t have the time or money to detect and remediate them,’” Hajost explains.
However, the speed of automated identification and remediation can save time by keeping waiver requests to a minimum.
“If you can use software to address all the CAT 2 and CAT 3 controls automatically in a very short time, you can reduce the number of waivers to the absolute minimum required. This saves costs, reduces the amount of documentation, and ultimately speeds certification,” Hajost concludes.
While many in government accept long delays as a fact of life, shaving months from the RMF accreditation process ultimately speeds the implementation of weaponry, communication, and other systems. Defense contractors and other technology providers should consider hardening systems in the accreditation phase and, when possible, during initial development.