Check out this blog post.  Wow, all sorts of crazies decend out of the woodwork when Bruce talks about something that’s been around for years and suddenly everyone’s redesigning the desktop from the ground up.

Quick recap on comments:

• 60-day password changes suck
• You can do this at home, the GPOs are available from NIST
• My blue-haired sheepdog can’t use the FDCC image, it’s broken for commercial use!
• You wouldn’t have to do this in Linux
• Linux is teh suxx0rz
• My computer started beeping and smoke came out of it, is this FDCC?

Proving once again that you can’t talk about Windows desktop security without it evolving into a flamewar.  Might as well pull out “vi v/s emacs” while you’re at it, Bruce.  =)

Computer Setup photo by karindalziel.  Yes, one of them is a linux box, I used this picture for that very same reason.  =)

But there is one point that people need to understand.  The magic of FDCC is not in the fact that the Government used its IT-buying muscle to get Microsoft to cooperate.  Oh no, that’s to be expected–the guys at MS are used to working with a lot of people now on requests.

The true magic of FDCC is getting the application vendors to play along.  To wit:

• The FDCC GPOs are freely available from NIST
• You can download images from NIST with a preconfigured FDCC setup
• Application vendors can test their product against FDCC in their own lab
• There is no external audit burden (yet, it might be coming) for software vendors because it’s a self-certification
• FDCC-compatible software doesn’t require administrative privileges

In other words, if your software works with FDCC, it’s probably built to run on a security-correct operating system in the first place.  This is a good thing, and in this case the Government is using its IT budget to bring the application vendors into some sort of minimal security to the rest of the world.

This statement is from the FDCC FAQ, comments in parenthesis are mine:

“How are vendors required to prove FDCC compliance?
There is no formal compliance process; vendors of information technology products must self-assert FDCC compliance. They are expected to ensure that their products function correctly with computers configured with the FDCC settings. The product installation process must make no changes to the FDCC settings. Applications must work with users who do not have administrative privileges, the only acceptable exception being information technology management tools. Vendors must test their products on systems configured with the FDCC settings, they must use SCAP validated tools with FDCC Scanner capability to certify their products operate correctly with FDCC configurations and do not alter FDCC settings. The OMB provided suggested language in this memo: http://www.whitehouse.gov/omb/memoranda/fy2007/m07-18.pdf, vendors are likely to encounter similar language when negotiating with agencies.”

So really what you get out of self-certification is something like this:

• IBM Rational Tools FDCC compatibility
• Quest Software FDCC compatibility
• SAS FDCC compatibility

• Comments on SCAP 2008
• NIST and SCAP; Busting a cap on intruders Part 1
• Ed Bellis’s Little SCAP Project
• Federated Vulnerability Management
• Security Automation Developers Conference Slides