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

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.

   

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

[Midnight Thunder]

Some of the stuff that they do is as boring as public relations and kitchen supplies.

Why would they possibly need the latest kernel version?

They probably believe it provides the kitchen sink ;)

Re:Who sets those minimum versions?

[Jaysyn]

The few DOD installations that my company has wired had two completely separate, very secure, physical networks. Big air gap between the secure PCs & the internet.

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.

repo

[arnodf]

add my repository, it has all the latest versions of everything, trust me, just update everything from my repo, you won't regret it...

Switch distros?

[HFShadow]

Take a look at gentoo, it'll definitely be bleeding edge enough to have the latest versions. Ubuntu server might satisfy your needs too.

I take exceptions!

[SoupIsGood Food]

Get ready for paperwork! You will need to apply for exceptions for everything that's out of compliance... I've worked in similar institutions, tho not the DoD, but most places run this the same way. The list of software in compliance is usually generated by the infosec team, and it's more of a wish-list than a demand... but to pass your audit, you will need to have permission to run out-of-spec software, and document why it's out of spec (vendor doesn't support that ver) and what you're using instead (the ver. the vendor supports). This is generally so the pen-test, NIDS and Intrusion Response people know what they're dealing with.

Have a chat with your info security shop - they'll walk you through it, and they're secretly envious of unix admins. They yearn for your aura of splendor and awe.

Re:Grindstone

[jd]

The most logical thing, surely, is to have a script that grabs the latest source, build suitable binary RPMs and a binary DEB, and then move these files to the correct directory for a repository manager.

(For RPMs, you could simply use the distro-supplied SPEC file and have the script replace values as needed. This only breaks when files are added/deleted, which usually doesn't happen.)

Alternatively, standardize on Slackware and banish the distro-specific issues to history. The drawbacks are less support and fewer fixes, but since the DoD can't track or test all variants, it's reasonable to assume they only track issues for the vanilla version. Distro-modded versions could have flaws added ad well as flaws removed, and in the DoD, it's better to have an absence of known threats.

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.

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.

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)

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.

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.

DISA Auditors

[KiboMaster]

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 :^)