This article is part of a series on STIGs that was originally featured on the Red Hat blog. To read this article – and the STIG series – in full, click HERE.
Secure Technology Implementation Guides (STIGs) as a framework for platform hardening, provide incredibly useful guidance for helping to attain the often required approvals to place systems in production, also known to some as an “Authority to Operate” (ATO). They do not, however, address all of an organization’s IT security needs for their environments, Even before a system hits production, organizations need to consider:
- How to handle vulnerabilities when they inevitably appear
- What needs to be done to extend or expand the role or footprint of a given system
- How to stay ahead of emerging threats
- What modernizing operations may look like and how it can be done
But what is “hardening” and what does it mean to modern IT deployments?
“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.
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.
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.
The Defense Information Systems Agency (DISA) does not assume that a STIG user has the deep product expertise necessary to do this. This expertise is crucial to understanding 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 equal 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.
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.