Page 126 - CDM-CYBER-DEFENSE-eMAGAZINE-December-2018

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.

According to Brian Hajost, president of SteelCloud and an expert in automated STIG compliance, there
are many misconceptions and confusions surrounding system hardening.

Only in rare instances do applications have specified STIGs. One example is Microsoft Word, which
when used in secure environments must be hardened. 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.

So, 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, but 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,” explains Hajost. “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.”

It is for this reason that RMF accreditation requires hardening the system as well as 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 now exist that include this type of
automated remediation.

ConfigOS from SteelCloud, for example, hardens all CAT levels (1/2/3) in about 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 is 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.

126