At long last, a version of the U.S. Government Configuration Baseline (USGCB) for Red Hat Linux Desktop is in the house. The first set of USGCB security requirements were created some five years ago by the Office of Management and Budget, specifically for Windows Vista, with the assurance that other OSes would follow. With the proliferation of Macs and iPads, I'm surprised not to see a USGCB for Apple products. How far behind can the mobile platforms be?
If you aren't familiar with the USGCB security recommendations, you should be -- even if they aren't required of your company. They provide a useful benchmark for comparing your own security requirements against those that have been reviewed time and again by professionals.
The current USGCB requirement is a collection of more than 337 security settings for Windows and 115 settings for Internet Explorer 8. They set a fairly strict baseline, somewhere between the EC (Enterprise Client) and SSLF (Specialized Security -- Limited Functionality) baseline from Microsoft, my full-time employer.
At times the USGCB has been too strict. Three years ago, I submitted 60 settings that I thought were overly restrictive, and there were at least 10 settings that almost no one implemented, such as enabling the FIPS security standard, which breaks nearly a dozen commonly used features.
What makes the USGCB such a compelling security recommendation is its multiyear review by hundreds of security experts and the people in charge of deploying it. Vendors, NIST (National Institute of Standards and Technology) employees, U.S. government workers, and the reviewing public have spent a good portion of their professional lives over the past few years seeking a good balance of default security and usability.
Having been intimately involved in that process at one time for a year, I can tell you it wasn't always pretty. Major applications and websites were broken and nerves frayed. But what has come out of the process is a fairly robust and accepted, aggressive security standard.
How aggressive? A good example is USGCB's requirement of a complex, 12-character-minimum password changed every 60 days or less. That's ambitious, especially for the government, which was known for simple, 6-character passwords just a decade ago.
I always recommend that my private clients look to the USGCB as a security model when considering what they should set as their corporate policies. If your password policy doesn't dictate 12-character passwords, ask yourself why the USGCB would require it. Could it be that all the password attack experts involved in creating the standard, including NIST and the NSA participants, did the math and figured out that 12-character minimums were necessary to withstand general attacks?
Notably, the USGCB standard applies only to normal, unclassified security systems. Higher-security systems actually require much stricter standards, including strong smart cards instead of solely passwords.
The USGCB's new Red Hat Linux Desktop standards are only in alpha release, but its 258 settings should be seriously considered by people in charge of implementing basic security on Linux/Unix/BSD systems (naturally, expecting that the settings specific to desktop Red Hat may not be applicable to your OS or computer roles).
Now, when will NIST develop the Apple-specific USGCB standards? These devices are, after all, showing up more and more and being connected to corporate environments and data.
This story, "Feds finally extend security baseline to Red Hat Linux," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.