Slashdot Mirror
Keeping Up With DoD Security Requirements In Linux?
ers81239 writes "I've recently become a Linux administrator within the Department of Defense. I am surprised to find out that the DoD actually publishes extensive guidance on minimum software versions. I guess that isn't so surprising, but the version numbers are. Kernel 2.6.30, ntp 4.2.4p7-RC2, OpenSSL 9.8k and the openssh to match, etc. The surprising part is that these are very fresh versions which are not included in many distributions. We use SUSE Enterprise quite a bit, but even openSUSE factory (their word for unstable) doesn't have these packages. Tarballing on this many systems is a nightmare and even then some things just don't seem to work. I don't have time to track down every possible lib/etc/opt/local/share path that different packages try to use by default. I think that this really highlights the trade-offs of stability and security. I have called Novell to ask about it. When vulnerabilities are found in software, they backport the patches into whatever version of the software they are currently supporting. The problem here is that doesn't give me a guarantee that the backport fixes the problem for which this upgrade is required (My requirements say to install version x or higher). There is also the question of how quickly they are providing the backports. I'm hoping that there are 100s of DoD Linux administrators reading this who can bombard me with solutions. How do you balance security with stability?"
I thought the DoD would forbid to run newer versions that haven't been ran and scrutinized enough by a lot of people.
I though they would do like many big iron companies that run older versions with security patches applied. I mean if I remember right, no later than last week, exploits were found in newer versions like Linux kernel 2.6.30 and Firefox 3.5. I think this is more likely to happen with newer releases of software than with older releases tested through the years.
Everything I write is lies, read between the lines.
DADMS is DoN-only for a reason; nobody else has the NMCI problem, and it didn't exist prior to NMCI. It's somewhat disconcerting to sit in on a meeting for a joint POR system, and have flag officers wonder WTF the Navy isn't implementing. "Uh, it's not in DADMS, sir." Sparks fly to say the least.
That said, the procedure is pretty simple, and since DITSCAP/DIACAP provide for it, you run specific vendor patches for whatever vendor-supported OS you're running (sorry Gentoo fanboys, roll-your-own isn't allowed in production systems). The Unix SRR script *should* be able to figure out if the backport is applied in a vendor-supplied patch, and pronounce it okay.
(The SRR scripts are publicly-available to everyone; if you're not running a commercial distro, you'll probably get some weird results, but it's still pretty good at picking out possible problems, even on systems that aren't officially-supported. I've run it on everything from Debian, including GNU/Hurd to OS X. http://iase.disa.mil/stigs/SRR/index.html)
If something is revealed that's not accurate, you document:
a) why you can't fix it (i.e. whatever system is running on top ceases to work, the vendor refuses to fix, the vendor is tango uniform, it's Wednesday and you don't feel like it, etc.),
b) why the scanner goofed up and picked out a problem that doesn't exist (yes, this version is different, but the vendor backported the fix [with proper vendor reference] to this, which is applied).
or
c) the fix hasn't been released and fully tested yet.
Cases a and c are what a POA&M is for, which is normally submitted along with the accreditation package, and updated periodically.