Oh, it certainly applies, it's just being ignored. I don't blame Congress for that, I blame the idiots that put these people there.

Any idiot can run an SRR. You actually have to know what you're doing to be able to look at the results and say "Yes that really is a finding... or No that's a false positive." Our clients are starting to come around to the concept that it pays to have someone do the analysis. If you don't, you'll end up having to go through the analysis phase yourself and then have go back and fight your auditor.

Someone should introduce Congress to the FISMA act of 2002, which mandates that federal agencies control for this kind of stuff. As part of my work at the DoD I occasionally audit non military systems. In the past this has included systems for the IRS, DHS and FBI. All of them are required to comply with FISMA regulations, specifically NIST 800-53. The relevant section, Appendix F Section SA-6 page F-222 (or page 293, for those reading the PDF) states:

The organization controls and documents the use of publicly accessible peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.

Now, I realize that's highly generic, but it's up to the organizational unit to write some sort of policy around the guidance. If they aren't able to do that, they're not in compliance with FISMA and the GAO should rightly be sticking a rather large boot up their ass.

I do IA work for the DoD. I primarily do Certification and Accreditation for the Department of Navy. The DoD 8500.2 controls require your operating systems to be Common Criteria certified. The EAL level is going to depend on your classification. There are several Linux distributions that have gone through the certification process. For specific versions of specific software (Linux Kernel, OpenSSL etc.) you're probably referring to the IAVA (IAV-A, IAV-B IAV-T) notices. These are specific known vulnerabilities that usually come from CVE or some other repository. They change as often as I change my underwear (insert joke about average slashdotter here). It would be impossible to keep a system up to date without significantly breaking functionality.

The thing I keep seeing is lazy DISA auditors that see the STIG's as black and white. Most of the testers I've run into aren't technical people. They run the automated SRR scripts and ding you for having your kernel version out of spec. If I were to sit them down and ask why a particular control was an open finding they'd tell me "Because the STIG said so" without digging deeper as to why.

The most recent test I was on, the testing team hit the sys admins for an out of date Kernel on a VMWare ESX box. VMWare uses a highly customized version of RHEL. Installing the most recent Kernel would turn the box into a paperweight. The best advice I can give you is to first check with the tester to find out exactly what the vulnerability is and what their recommended fix action is. Depending on your tester you may be wasting your time. I've see far too many tester leave comments like "Not up to STIG compliance". Check with your vendor to see if they have issued a patch to address that vulnerability. Once you have that information you can place your comments into a POA&M and go back to your DAA and explain why a given open finding isn't really a finding and/or won't be fixed. You can also look into mitigation factors to see if you can reduce the severity. Many controls will state "If you're doing X, Y and Z this finding may be reduced from a CAT I to a CAT II".

Good luck with your C&A and be glad you're not on the documentation side of things :^)

DeepThought
Earth
Hactar
Eddie
Marvin