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.
I smell something fishy. Sounds to me like whoever is making money off securing DoD systems is also involved in specifying what versions to use. If you run something that's been battle tested and known to be "safe" (relative term) then there's no money to be made.
Here's a cheap way to make DoD Linux systems safe: don't connect them to the public internet, period.
1) Does the DoD contribute heavily to security software programs or packages? If so, they probably know which libraries are needed as they've been using them to provide the updates.
2) Maintenance of multiple server systems is always difficult. This is why Rocks was developed and why some develop their own startup and build scripts for clusters or server farms. Advanced scripting techniques are a must in a large environment.
3) Even if DoD doesn't contribute, they'll always point out the latest stable software and security fix. If you're talking about the defense of the country, how could you say, "We recommend this version...the one with the security hole that was fixed in the next version."
That was my first thought. If the DOD requires specific versions- they should maintain repositories of them on their own servers. Perhaps one on their secure/classified network, and one on a more accessible network. They could be writable by only a few key people, so their chances of become corrupted would be very low.
First of all, if you work for the Navy, the distribution must be within DADMS, so you can't just run any random distribution. I also run a few linux machines for the DoD (the Navy specifically). The rules are enforced by the scanners. I take the vendor's (RedHat in my case) backported patch at their word, that they have fixed it. If you read their patch documentation, when the security alert is issued, that they have implemented the patch. The network security scanner doesn't pick up that you have patched it, because the version number doesn't match. I submit the RedHat's patch document with the report, as evidence that I have done it. It satisfies the auditors, because, to them, it's no worse than trusting Microsoft that they have patched their stuff. I don't have the time to investigate and test to see if the vendor actually fixed the problem with their backported patch. I leave that for the security exports to ping on them if they failed to do their job. Besides, that's what I'm paying RedHat for. I don't have the time to make sure that Microsoft fixed all of their stuff either. I patch and go, and document it what I have done. As long as their is a paper trail to prove that you have been patching, all is well.
Ol' Rick Dawson had a farm EIEIO
Congratulations. It's now your job to check every *single* *freaking* *package* where the DISA specs proscribe a particular version, and see whether or not your vendor backported the security fix. Usually the DISA specs will contain a vulnerability id (CVE-ID or similar) that you can reference against. Google is your friend. The overall process is murder. It's a big reason why I got out of government IT. On a related note, I find the Linux vendor practice of keeping old version numbers, but backporting new fixes into their own trees (Red Hat's "version x.y.z-ELsomeothernumber" system for example) to be categorically infuriating, but that's a different rant. --jwriney