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

Comments

Let the process work.

[tprox]

Apply for a waiver on those requirements :)

Re:Let the process work.

[bcong]

He's not kidding. The waiver is called a Plan of Action and Milestone (POA&M) if he's going by the DoD/DISA IA vulnerabilities and their vulnerability management system. This is the only way they can actually set maintenance schedules. A lot of the admins submit these 'waivers' with a plan of action which includes quarterly or monthly patch days, otherwise they'd have to run patches every other day, possibly breaking their applications and services. It's a lot easier to bulk patch and test the app/service once a month or quarter than every day. The frequency of DoD IA notices is so high that this is the only manageable solution.

Re:Who sets those minimum versions?

[YrWrstNtmr]

Jesus christ on a crutch. If I see this stupidly retarded statement one more time...
If you've been here on /.more than about 3 seconds, you would have come across a little tidbit of information alluding to the different networks within the US DoD, and their various levels of security. Not everything that lives on a hard drive in the DoD is sooper sekrit and needs to be cut off from the outside world.

Some of these networks are truly open. Some are only acecssible from a .mil domain. Some are not connected to the internet at all, and split with an air gap. And some even more restrictive than that.

Your oh so insightful remark is also a cheap way to hamper operations.
We need a -1 Dumbass.

Weigh each vulnerability individually

[Bryan_Casto]

There are many, many ways to deal with this, but fortunately while DoD says "update to this specific version," what they really mean is "close this specific vulnerability." Get used to hearing about IAVMs and VMS (Vulnerability Management System).

Taking the case of OpenSSL specifically, it's not uncommon for there to be patches released for vulnerabilities affecting a previous version. If you're using a vendor like Redhat (and in the mind of DoD, Redhat/SuSE = Linux, and nothing else) what you'll end up with is a version of OpenSSL that appears vulnerable, but in fact has a backported patch applied to the vulnerable distribution. Once you've applied the updated RPM, you can say in good conscience that you've mitigated the vulnerability, and you can close the finding.

Where it gets stickier is where you have code that depends on a specific version of a library that might be vulnerable. In that case, you need to dig in and understand the specific uses and how you might be able to mitigate the vulnerability by turning off a publicly listening service or applying some strict file controls, or maybe you don't exercise the vulnerable function in the library and can justify it that way.

Ultimately, you have to be able to convince your DAA (Designated Approving Authority) to accept the risk. If you can't immediately close the issue, you have the option of doing a POAM (Plan of Action and Mitigations) that will outline how you're going to mitigate the issue until you can close it.

There are a ton resources, but specifically I'd start here:

http://iase.disa.mil

You also might find this interesting as a way to secure Redhat machines:

http://people.redhat.com/jnemmers/STIG/

Feel free to contact me if you have more specific questions as well.

Where are you finding these "requirements"?

[SpaFF]

I am a Linux administrator at a DoD site. I have never seen anything that says that you must run kernel 2.6.30 or anything like that. Can you please provide a link to where you read this? (links to CAC-authenticated websites are ok)

DoD I-8500.2 requires you to run an OS that is EAL certified at a certain level depending on your classification. The only Linux distributions I know of that have EAL certification are SLES (9 and 10) and RHEL (4 and 5). I keep hearing about people that run things like Fedora, CentOS, and Ubuntu on DoD networks, but I have no idea how they get away with that.

As far as software versions go, what versions you must be at are dictated by IAV-A, IAV-B, and IAV-T notices. The IAV-A may say that there is a vulnerability that affects kernel versions = 2.6.30 and that you must go to 2.6.30 to be compliant, but as long as your vendor's kernel version addresses the CVEs that the IAV-A references then you are covered.