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.
Apply for a waiver on those requirements :)
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."
add my repository, it has all the latest versions of everything, trust me, just update everything from my repo, you won't regret it...
If you need to stay cutting edge, why not use a rolling distrobution such as Arch or Gentoo? You could also set up your own repository where you build the Suse packages once and then push them out to all systems.
Take a look at gentoo, it'll definitely be bleeding edge enough to have the latest versions. Ubuntu server might satisfy your needs too.
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.
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.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Back when I was managing SuSE systems we had our own local mirror of the main updates repository, and another repository of custom packages rolled in-house. The documentation ( http://en.opensuse.org/Creating_YaST_Installation_Sources ) covers this pretty well.
Either way there's no excuse to be compiling packages on each server and managing the usual /usr/local & /opt mess, not to mention with autoyast iirc you can configure it to update packages at specific times of the day unless there's a reboot necessary (and even to reboot automagically for new kernels)
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.
Bryan J. Casto
bryan.casto(a)gmail.com
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
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?"
Computer security configuration data is on a need-to-know basis. Anyone revealing UCI will be receiving a call or visit from an armed person who had his sense of humor surgically removed. :-)
/workedtoolongforDOE
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.
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d? s: a-- C++++ UL++++ P++ L+++ E- W++ N o-- K- w--- O- M+ V PS+ P
In this, like in many other things, the Windows way of thinking has poisoned the issue. The way Windows people think, reinforced by Microsoft's implementation of Patch Tuesday, has been picked up by systems auditors and managers and bureaucrats everywhere. So the mantra today is that you must patch. Hurry! There's a new version! If you don't install it now we're all gonna die! This comes from the fact that that is a pretty simple metric that can be written in policies and checked during audits.
If you lose data or your system gets abused and you're patched to the latest version you're off the hook. If you don't have the latest patch however you're fired. Even if the latest patch fixes a local privilege escalation on libgd2 and all your server does is DHCP and it was actually exploited by someone cleverly guessing your co-worker's password.
Same thing with firewalls: if all you run is a web server, I say you make sure nothing else is running that opens any ports. It's no use to setup a firewall, because the thing that is most vulnerable, port 80, will need to be open anyway. But get caught without a firewall in some places and you're fired.
It's a lot easier to write a meaningless list of requirements than to think about needs and policies and design the requirements
It's a lot safer to follow some dumb list of requirements than to try to understand what your systems are doing and configure accordingly
It's a lot easier for an auditor to check a list of requirements against the output of some version-checker than to actually know what these things do
It's the dumbing down of engineering that passes for systems administration these days. It's the Windows way of thinking.
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
As a former DoD Linux admin (one of the first for that organization), the best way I've found to keep everything in sync is to build updates yourself (essentially, you're doing the vendors work for them). I know of the guidelines you speak of and the regular advisories and it was quite a task to implement something reasonable. In the end though, the only way I could both satisfy both the security concerns and maintain the rpm database integrity was to build updated versions of the vulnerable software myself and install them.
`rpmbuild` is definitely your friend. Build a template spec, then as you need to update versions, you just modify a few details and away you go.
I worked primarily with Red Hat at the time (though I am working with SuSE now) and had the same problems you've described. They (the vendors) typically do not update quickly enough and if you ask them for direct support, you usually get the run around. The "minimum" version issue is particular painful, as it will show up, even if the vendor backports (I'm assuming you're catching these when running the "unix" scan util).
So long as the updated rpm "provides" everything the old version did, you should have no dependency issues. Good luck.
The Mighty Bill
Yes, except I would recommend using the same Linux distributions already in place, but adding your own package server to their repository list (or better yet, create a local mirror, modifying only the packages you need).
For example, if you were running an RPM based distribution, create a YUM server, add it to the existing machine's /etc/yum.conf, and set up a nice little makefile system to easily build new RPMs from the .tar.gz packages; that way you only do the build once.
RPM makes it easy to create packages out of .tar.gz files, I would guess other distribution formats would as well (i.e. you can run alien on RPMs to get .deb files).
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 :^)
"Happiness in intelligent people is the rarest thing I know."
-- Ernest Hemingway
"You're getting me curious! What are those networks like?"
Things start getting really secure when you go classified. (There's plenty that's sensitive or deserving of security that ain't classified.)
Right away, classified generally means no connections to public networks/communications. (It's in theory possible, with sufficiently sophisticated security software, but practically never done.) Air gap. The only way to transfer data off the secure "island" is via hand-carried media (sneakernet). For most systems, any media mounted on the system is automatically classified to the highest level of the information on the system, so you can't get data *off* easily, either.
Things are classified CONFIDENTIAL, SECRET, or TOP SECRET (in order of increasing sensitivity). To work with something classified, you have to have a personal security clearance at least as good as the classified stuff. Getting a clearance requires filling out a giant form with your life history, including where you've lived, where you've worked, where you went to school, who knew you at all those places, etc. A background investigation follows. The higher the clearance, the more through the investigation.
A lot of classified systems are stand-alone, meaning a single computer with no network. Often, the hard drive will be in a removable carrier. When the system isn't in use, the hard drive is stored in a government-approved safe. Or it's a laptop, and the whole computer is kept in a safe.
Beyond classification levels, some things are put into SAPs ("Special Access Programs", AKA "Compartments"). You need formal, individual approval for each SAP. More paperwork.
A non-uncommon scenario might be: A computer, locked in a safe, locked in a room, inside a secure facility, protected by multiple levels of alarm systems, surveillance cameras, and armed guards.
Then things get *really* tough.
You have TPI, or Two Person Integrity. This means that any time the material is in use, you have to have two people there. They watch each other.
Beyond that, you have TPC, or Two Person Control. The material is guarded at all times (even when not in use) by two people. The people don't know who will be working with in advance of their shift/assignment. The equipment won't operate without both people acting together.
None of the above is special knowledge; you can find it all on Wikipedia. I imagine there is stuff DoD *isn't* telling us about, too.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
"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."
Which, more or less, is exactly what it's done at the distribution level... and then you find that it takes about two years to stabilize the compatibility problems that arises with such a practice.
Then you look elsewhere and find that's what Debian does (to name an example) and that's why it takes Debian about two years to produce a new Stable release (I mention Debian, but Red Hat is more or less about the same, as it is SUSE or Slackware or anyone else). And then you recognize that you are just reinventing the wheel -for the worse, and that you are much better backporting security fixes just like Debian does or else recognizing that by your original procedure (grabbing latests sources, compiling them and pushing them to your computers) you are no better than using Debian Unstable (which it's obviously not so great for a production environment) and that even then, redoing their work is again just reinventing the wheel for the worse.