Surviving the DISA UNIX STIGs

Understanding the DISA UNIX STIGs is difficult for first-timers and sends chills down the spines of system administrators who have used them before. They are probably the most detailed set of security controls available which apply to a wide variety of operating systems.

The biggest complaints from system administrators are that the STIGs are time consuming and require benign or seemingly useless settings. Personally, I think they are great. They are worth the time because they will improve your security posture and most system administrators learn a great deal during the implementation process.

The Security Technical Implementation Guides (STIGs) are published by the U.S. Defense Information Systems Agency's (DISA) Field Security Office (FSO). There are three pieces:

1. UNIX STIG V5R1 (April 2006) — This is the main document and it gives plenty of explanations, rationale, and general information.
2. UNIX Security Checklist (published quarterly) — details the requirements by line item to include what to look for in configuration files as well as commands to be executed.
3. System Readiness Review (SRR) Scripts (published quarterly) — scan the operating system for compliancy. To download, you must have DoD PKI access.

Too often system administrators download the SRR scripts, run the scan, and then perform the manual review. Then they bounce between editing configuration files and re-running the scan. Before you run any script on your system, there are some things I would recommend.

First and foremost, make sure you have a Disaster Recovery Plan or some sort of Business Continuity Plan (BCP). The plan must contain detailed procedures for performing backups and recovery.

Wherever possible, try to have on-line, off-line, and off-site backups. On-line could include storage mirroring technologies and off-line could be some sort of media which isn't connected to equipment.

If at all possible, perform encrypted backups and then store them in a media safe on-site and off-site. The off-site backups could be as simple as taking the off-line media outside of your data center and preferably not in the same building.

Account management and personnel security practices must be clearly documented. This includes documenting how access is granted to personnel. Procedures on removing accounts or revoking rights must also be documented.

This also means taking a serious look at shared application and administrative accounts. Stop logging directly into these accounts (especially root!) — personnel should be logging into their own personal account then switching to the application/administrative account.

The biggest tip I can offer is to REMOVE ALL SOFTWARE WHICH IS NOT NEEDED. This is where you gain great insight to your system's architecture because you will learn what components rely on what.

For example, if you are not using any features or utilities of Samba — remove it. I hear some administrators complain about the results of an SRR because it found problems with their Samba configuration.

Their argument is "We aren't even running the daemon!" If that's the case, simply remove the package — it will reduce your findings and the amount of software you must constantly patch, upgrade, and report on.

Lastly, have a STRONG, aggressive patch management plan. Make sure you have a complete backup of your system and patch everything you can. Next, download the "UNIX Security Checklist" and familiarize yourself with Section 3 of the document.

Once you've done all of the above, feel free to perform your first SRR scan — which will take about 3 to 5 minutes to complete.

Once the Start-SRR script and manual review scripts have been run, you are ready to begin configuring the system to address failures. This is where it can get confusing for some people.

Each test result is bound to a line-item, or more correctly a Potential Discrepancy Indicator (PDI). For example, the SRR reported that PDI GEN003600 failed:

Beginning GEN003600 on 04/25/10 at 06:38.
Network parameters are not securely set.
Finished GEN003600 on 04/25/10 at 06:38.
::::::::::::::
/root/Desktop/Script.February/centos-5_2-i386.localdomain/GEN003600.Examples
::::::::::::::
GEN003600: net.ipv4.tcp_max_syn_backlog tunable is set less than 1280.
::::::::::::::
/root/Desktop/Script.February/centos-5_2-i386.localdomain/GEN003600.log
::::::::::::::
::::::::::::::
/root/Desktop/Script.February/centos-5_2-i386.localdomain/GEN003600.Result
::::::::::::::
PDI Number: GEN003600
Finding Category: CAT II
Reference: UNIX STIG: 3.20.5
Description: Network parameters are not securely set.
Status: Open
For example: GEN003600: net.ipv4.tcp_max_syn_backlog tunable is set less than 1280.

Now you must figure out how to configure the system so it will pass subsequent SRR scans. Section 3 of the Checklist document simply states the following:

GEN003600 – Network Security Settings

Perform the following to ensure the network security settings are enabled for each operating system. The command is listed with the expected response below it.

....

Linux

# sysctl –a | grep net.ipv4.ip_forward
0
# sysctl –a | grep net.ipv4.tcp_max_syn_backlog
1280
# sysctl –a | grep net.ipv4.conf.all.accept_source_route
0
# sysctl –a | grep net.ipv4.icmp_echo_ignore_broadcasts
1
...

Unfortunately, the guideline does not tell you how to set the value correctly. Most system administrators would check the manual page on sysctl(8) and learn that you can use the -w option to set the parameter in the running kernel. However, if you reboot the system the kernel setting would be lost because it was not placed in the /etc/sysctl.conf file.

Situations like this are compounded when dealing with multiple operating systems which require different methods to implement the security setting.

Once the setting has been configured, test the applications on the system. If any problems arise, the change must be reverted and you must document why it was not implemented. You must also document any reasons or other configurations which mitigate or reduce the risk of not configuring the system accordingly.

There are 368 PDI(s) so, you better get yourself a cup of coffee.

Once the system has been configured and tested, it should be baselined and its current configuration well documented. Each time new software is introduced or existing software is patched, another baseline should be taken and compared to the first. Identify any changes and correct the security settings to ensure you maintain the same security posture. As a matter of fact, DISA recommends running weekly baselines to detect any changes in the system.

This laborious process is one of the reasons Security Blanket® is becoming so popular. Security Blanket will automatically configure your system so issues such as GEN003600 are completely transparent — regardless of the operating system it is running on. If you're skeptical, check out the free trial.

Cross-posted from Security Blanket Technical Blog