On the road to platform hardening, consider a STIG

Have you ever leveraged a STIG for platform hardening?

In an informal poll of eight of BlueCat’s customers, it was an even yes/no split.

Platform hardening is the process of securing systems by reducing your attack surface. By doing so, you’re reducing the avenues for threat actors to find and exploit vulnerabilities.

Developed by the U.S. government, STIGs are a specific structure for platform hardening. They are a methodology that standardizes security configuration within networks, servers, and computers to enhance security. Federal networks use them but they can apply to any enterprise.

Certainly, STIGs are important for DNS, DHCP, and IP address management (together known as DDI), given the critical role they play in network infrastructure and their popularity for attackers.

This post will cover the four general types of platform hardening. And it will examine STIGs in-depth, including what they are and how to get started using them in your enterprise. Finally, it will look at how BlueCat incorporates them into its products.

The small group of IT professionals who discussed these ideas is part of BlueCat’s open DDI and DNS expert conversations. All are welcome to join Network VIP on Slack.

Types of Platform Hardening

There are generally four types of platform hardening.

Informal hardening

Informal hardening can encompass several techniques. It might include separating services—like web, file, and mail servers—so that they are not on a single box. Another measure would be providing the least amount of access needed for services to perform their function. A third technique would be disabling or removing unnecessary services like FTP or Server Message Block (SMB). Or closing open network ports that aren’t actively used.

Formal security frameworks

Formal security frameworks for hardening include Security-Enhanced Linux (SELinux). A security architecture for the Linux operating system, it gives admins more control over who can access it. AppArmor is another example. A Linux security module, it allows admins to secure permissions for specific applications by using profiles.

Security guidance

The U.S. federal government’s Defense Information Systems Agency (DISA) publishes security requirements guides (SRGs). These are guidelines to mitigate security vulnerabilities commonly found in a technology family, product category, or organization. They are not product-specific.

Formal hardening controls

Formal hardening controls include measures like implementing firewall rules and containerizing services.

The U.S. government’s National Institute of Standards and Technology (NIST) publishes measures for formal hardening control. NIST also publishes a catalog of hundreds of security controls for IT systems that support the federal government.

Finally, the last of the formal hardening controls are STIGs.

What is a STIG?

DISA developed the STIG, which stands for Security Technical Implementation Guide, more than 20 years ago. It details specific configurations to make on a system or product to make it more secure and, ultimately, STIG-compliant.

Updating of STIGs is constant. Today, the public can access about 500 unclassified ones. Nearly every type of common software or system you can think of—from Adobe Acrobat to Ubuntu—has one. Several STIGs are specific to DNS.

STIGs break the abstract concept of information security down into discrete and granular steps. It gets pretty specific: e.g., set this option on this configuration file. Ultimately, they make security measures auditable. By following a STIG, two auditors can look at the same system and come up with consistent assessments.

The STIG approach in your enterprise

Getting started

The steps to getting started with STIG compliance are pretty straightforward:

1. First, pick your operating system or software application to secure.
2. Next, find the relevant STIG. DISA’s STIG document library houses all of the unclassified ones for downloading (the library hosts SRGs as well). Their publication is in XCCDF, or Extensible Configuration Checklist Description Format. This is an XML format used for security checklists, benchmarks, and configuration management documentation.
3. After that, download the zip file for your guide and then view it in the STIG viewer. As XCCDF is not the simplest of formats to work with, DISA has also created a very useful STIG viewer. You can import your files into the viewer and it will do all the parsing for you.
4. Then, create your own checklist. With the viewer, you can create a checklist from all your guides and track your progress.
5. Finally, begin identifying in-scope configuration changes to make and track on your checklist. Pie charts will provide visuals of your progress, too.

Completing the checklist does not mean you’re done

To be sure, systems hardening is an evolving process. As a customer put it,

STIGs are the beginning of a journey, not the end or the final steps of your journey. So don’t be lulled into, ‘I’ve STIGed it and now I’m OK.’ It requires vigilance because STIGs change on a regular basis.

Additionally, it’s important to recognize that STIGs might not apply in every case. Perhaps you can’t complete one for a particular application. However, the fact that all your network traffic runs through a firewall before it gets to it can be equally adequate mitigation. A customer familiar with STIG audits further explained:

You don’t have to meet that STIG because it’s actually being done at the firewall. There’s a lot of interpretation. There’s a lot of interaction that has to be taken into account when you go down the path of trying to STIG something. If you’re not following a STIG setting in Postgresql, that’s OK if there’s a mitigating factor or a recommended mitigation that you make.

How the BlueCat platform incorporates STIGs

BlueCat Integrity has long had a STIG compliance option. Users can enable it on a per appliance basis through the administration console. It gives customers automated compliance with several Unix-related STIGs (and SRGs, for that matter). No need to apply configuration changes yourself.

BlueCat conducts regression testing, ensuring its products work correctly when enabling STIG mode.

If you need help enabling STIG compliance in BlueCat Address Manager, BlueCat’s product documentation has you covered.

Furthermore, BlueCat’s software security team is also looking into compliance with additional STIGs for future product releases. Do you have a STIG requirement that you’d like to see BlueCat put on its product roadmap? Let us know.