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 am surprised

[ls671]

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.

   

Who sets those minimum versions?

[PingXao]

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.

A few things

[lymond01]

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."

Re:I am surprised

[vertinox]

I thought the DoD would forbid to run newer versions that haven't been ran and scrutinized enough by a lot of people.

Depends on who you work for and what you do.

Not everything various DoD employees do is related to a "super secret project".

A lot of stuff in the DoD doesn't really have the need or want to be super scrutinized. Some of the stuff that they do is as boring as public relations and kitchen supplies.

Re:Military Mirror

[neowolf]

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.

trust the vendor

[OlRickDawson]

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.

Backports FTW

[jwriney]

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

Re:trust the vendor

[idiotnot]

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 [disa.mil])

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.

Re:Who sets those minimum versions?

[drinkypoo]

You're getting me curious! What are those networks like?

I can give you some examples of their restrictions, and I didn't even see the room. In fact, I was supporting an enterprise management package used at their site, and I wasn't even allowed to know where their site was. They're not allowed to have any communications lines or devices inside the room, so doing support involved talking to three people really; one person actually on the phone, shouting to the guy holding open the door, shouting to the guy sitting at the keyboard. And keep in mind that this is a Unix-based site (I forget which one, sorry, it wasn't the interesting part of the call) and I'm giving them CLI commands... punctuation and all. Amazingly enough, I never had to repeat anything. This suggests to me that everyone over there was competent, which further suggests that it was actually an important site :)

The door on the room closes and locks itself per restrictions, and propping it is a big big big no-no, hence the guy in the doorway. You can't use a walkie talkie in the room let alone a telephone of any sort, hence the shouting. And the support tech is only allowed to know as much as he needs to know to answer your call. So that's what the next step is, I guess, after the air gap.