Government agencies are not known for moving quickly, and the Risk Management Framework (RMF) accreditation process is a prime example. For defense contractors and integrators tasked with developing new technologies for the Department of Defense (DoD) and other government agencies, this step alone can take nine to 12 months or longer.
The glacial pace of accreditation is due to the manual nature of the review process tasks, as well as significant documentation and system hardening required to meet security policy mandates. Without this step, projects cannot move to Authorization to Operate (ATO). In short, any delays impact deployment of new defense technologies in the field.
New automated software tools are eliminating weeks, if not months, from the RMF accreditation process by virtually eliminating the time of the initial hardening while also providing the required documentation. By doing so, technology integrators can significantly reduce the time to build, test, and deploy new technologies in Security Technical Implementation Guide (STIG)-compliant environments.
The DoD introduced the RMF in 2014 to assist federal agencies to better manage risks associated with operating information systems.
As part of this process, systems must be hardened to standard STIG benchmarks from the Defense Information Systems Agency (DISA), the entity responsible for maintaining the security posture of the DoD information technology (IT) infrastructure. The STIGs provide configuration specifications for operating systems, database management systems, web servers, and network devices used by government agencies. The DoD uses STIG audits to analyze risk and identify configuration vulnerabilities. The configuration settings are classified using Defense Information Systems Agency Field Security Operations (DISA FSO) Severity Category Codes (e.g., CAT levels).
The problem is STIGs are long and detailed, often containing hundreds of pages. Adhering to or upgrading software or systems to a particular STIG has been a highly specialized manual process that can take many weeks to accomplish. In addition to the significant time involved, it requires well-trained engineers that are skilled in the technical system, operating system policies, and security guidance. Further, system hardening is often accompanied by many misconceptions and much confusion, affirms Brian Hajost, president of SteelCloud and an automated STIG compliance subject-matter expert.
Only in rare instances do 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,” which includes the operating system (Windows, Linux) the application is built upon as well as web browsers, databases, and other components required for the application to function.
When an application is implemented in a STIG-hardened environment (i.e., changes have been made to the underlying operating system, for example) it inevitably runs into conflicts that can cause the application to “break.” When the application is an electronic document, that may be problematic; for a military firing system, it can be a matter of life and death.
“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.”
For this reason, RMF accreditation requires hardening the system, providing significant documentation of the hardening, as well as details of all CAT 1/2/3 controls – a categorization of the degree of security risk.
Automating the process
Given the manual nature and expertise involved in hardening and documenting all changes, it would be easy to assume that multiple, competing software solutions already exist. This is not the case.
Vulnerability scanning software is available that can compare generic STIG signatures to identify controls. This only serves to highlight the problem areas but does nothing to 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 must often be used in conjunction with vulnerability scanning software.
Even if both are used, however, these options do not make changes to controls that are specific to the application stack involved. Fortunately, more complete solutions exist that include this type of automated remediation. ConfigOS from SteelCloud, for example, hardens all CAT levels (1/2/3) in roughly an hour, including producing a domain-independent XML signature and documentation of all required waivers. In this step alone, weeks or months of manual work can be eliminated.
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 also easily be included with applications as they are transferred to disparate infrastructures from one mission partner to another. Using the signature, scanning, remediation, and compliance reports are accomplished in roughly one minute. Because STIGs are updated every 90 days, the software also simplifies updating systems in production.
“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.”
DoD officials will not authorize the issuance of an authority to operate (ATO), for example, of systems with an unmitigated CAT 1 vulnerability except under extreme and rare circumstances – which can mean sending a project back into development to address the issue, Hajost explains.
“Now a ‘fix’ that would have cost $500 in the initial development can cost the government many thousands of dollars,” says Hajost, adding that it is the primary reason to address STIG hardening as early in the DevOps process as possible, even before accreditation. “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, waiver requests must be submitted for review and acceptance by accrediting authorities.
“We have seen examples where developers have even said, ‘We're just going to waiver all the CAT 3's because we don’t have the time or money to detect and remediate them,’” Hajost adds. However, with the speed of automated identification and remediation, more time can be shaved off timelines 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 period of time, you can reduce the number of waivers to the absolute minimum required. This saves on costs, reduces the amount of documentation and ultimately speeds certification,” Hajost says.
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, communications, and other systems. With this in mind, defense contractors and other technology providers are increasingly hardening systems in the accreditation phase and, when possible, during initial development.
Jeff Elliott is a Torrance, Calif.-based technical writer. He has researched and written about industrial technologies and issues for the past 20 years. More information about ConfigOS from SteelCloud is available by phone (703-674-5500) or online at www.steelcloud.com.