Beyond the STIG: What hardening really means

This is the second of a series that examines IT security and cybersecurity practices beyond Secure Technology Implementation Guides (STIGs). Read the intro post here.

“Hardening,” as a software concept, is a common term but what the practice actually entails and why it matters for contemporary IT organizations is not often explored. Hardening is crucial for every organization, even those that may also use particular STIGs or configuration guides. 

Hardening refers to the practice of reducing a system’s attack surface, thereby enhancing its overall security posture. An example of this is disabling or removing unnecessary features and functions, causing your system to operate in a more restrictive manner than it would by default. Or another method might be to limit privileges, or eliminate them completely, of a component to use features (APIs, files, etc) of another component. In this way, hardening allows only the authorized system components to be used. 

Figure 1: A hardening guide often removes capabilities to limit attack surface. In this example, the RHEL STIG limits available cryptographic algorithms and protocols – here removing the potentially unsafe TLS 1.0 and 1.1. 

STIGs provide guidance that is a starting point for system hardening. DISA STIGs concentrate on a single product rather than an integrated system and are rote by design, as they make numerous implicit assumptions about external systems, business procedures and non-technical controls. They also assume common threats, risks, and usage models that may or may not be applicable. STIGs are made to offer straightforward instructions to the implementor, who is typically a system owner or technical administrator. DISA presumes that these users do not have a thorough understanding of the target product or the security implications of the various implemented controls. Therefore, STIGs are often written in simple and unambiguous terms to reduce uncertainty when applied or audited, and exception processes are needed when there is a deviation.

Figure 2: Multiple weaknesses may be present even when a STIG is applied to the target system. In this example, infrastructure, supply chain, database processes, enterprise management systems may allow various attack techniques. Often, external processes or tools, or simple human errors, introduce risk to otherwise hardened systems.

So where does hardening enter the picture? A STIG can aid with the default hardening, but much more must be done to keep up with an evolving and growing landscape of software threats and vulnerabilities. Even just determining which CVEs apply to an existing IT system is a significant task, but one that Red Hat and other software vendors regularly fulfill for their customers (see Red Hat Security Advisories, Red Hat Security Bulletins, and OVAL data feeds or CSAF data feeds). The Defense Information Systems Agency (DISA) does not assume that a STIG user has the deep product expertise necessary to do this. This deep expertise is crucial to understand a product's attack surface through static testing (SAST), threat modeling and penetration testing. Suppliers like Red Hat are best positioned to incorporate this understanding with other guidance from, for example, NIST's Secure Software Development Framework (SSDF) or OWASP guidelines to provide default hardening guidance. Documentation in the form of deployment and security guides equips end-users like DISA to tailor these to their own specific hardening requirements based on historical attack patterns they experienced.

Hardening can aid in preventing systemic attacks, as fewer attack surfaces equals fewer opportunities for exploitation by decreasing complexity and opportunity for errors including security defects. Hardening helps prevent unauthorized or unintentional system changes that could have detrimental effects if not properly controlled. The practice of hardening can also help reduce the number of active services on the system, limiting other attack or exploit vectors. Additionally, if a bad actor is successful in accessing the system, hardening principles can limit the potential for lasting damage. Common hardening objectives such as logging and monitoring subsystems and their external integrations can alert or aid in detecting attacks or compromise of  data and operations, or actors using lateral movement techniques to expand their reach and access.

Figure 3: In this example, we see a hardened default configuration applied to Red Hat Openshift Container Platform’s HAProxy based ingress controller to provide improved defaults for connection timeouts, secure cookie handling, and forwarding headers (& others not shown).

Hardening can help to improve the overall security posture of the system. This is particularly important in environments where the system is required to meet certain industry or government security standards or other configuration practices. By following specific hardening guidance from organizations, such as DoD elements following DISA’s STIGs, system owners can have some confidence that their systems meet IT security benchmarks and are compliant with the appropriate industry regulations.

In our next post in this series, we’ll talk about how involvement in open source communities can help shape the future of vulnerability management and why this matters to end users.