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.
You'll probably have to solve it by using build scripts and tarballs. If you're feeling really ambitious, up the ladder and find out why it's only by version. Finding versions for each distro is probably more work for the people who do the list.
SIG: HUP
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.
Can you set up your own private DOD repository to hold those newer versions? Beats updating a ton of PCs manually.
There is a war going on for your mind.
"I've recently ***been fired from my job for telling everyone I'm*** a Linux administrator within the Department of Defense." ... fixed.
Sorry to sound like a jerk, but isn't this what you're paid to do?
What, create time?
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
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.
If it is an issue I am surprised there is not a military mirror.
Why would not CyberCommand (or whatever it is called) maintain a mirror of OS they approve of.
It is easy enough to set up and they can log all the machines to make an inventory. Even make sub-mirrors for different commands.
Take a look at gentoo, it'll definitely be bleeding edge enough to have the latest versions. Ubuntu server might satisfy your needs too.
DOD does not mandate software versions for the most part. The notion that DOD requires kernel 2.6.30 right now is completely wrong.
They mandate patching specific vulnerabilities, but that doesn't require upgrading to the latest software version. RHEL is a great example of a distribution that patches vulnerabilities without updating to the latest major versions of specific software, and RHEL is widely used by the government and military.
You're going to need time (or a team) and some custom solutions. You're looking for something like pkgsrc methodology where you can push the same packages out on different machines regardless of their distro, and some really great management software for it all.. like puppet or something along those lines.
This all sounds like a kludge and the Wrong Thing to Do(tm).
If the Linux distros in question are the same, you could probably leverage the distros package management system. For instance it wouldn't be all that difficult in Debian realistically, depending on which packages they were worried about. Desktop, forget it, nightmare city.
I foresee a lot of testbed work!
Something seems wrong though, I'd be surprised if there wasn't either a secure internal repo or a more sane way that "always get the latest!! omgz".
that's not surprising, or you're not paid to administer linux systems.
really, now.
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 biggest problem that I think you are experiencing is that you seem to have an expectation that mandated requirements in a governmental sphere are completely sane and workable. I am trying to see how I can phrase this without just making a sweeping generalization about the inefficiency and beauracracy that is attached to things run by the state. In general, I would say that the primary reason for this is that, in the public sphere, it is easier to attempt to solve a problem (real or imagined) by taking another thing on top of the pile rather sorting through issues and finding the actual root cause and resolving that.
So, having said that, don't expect all policies to make sense while working for DoD. If you are fine with that, just do what you are told as best you can with plenty of CYOA. If you are not fine with it, don't try to fight it. Go work elsewhere.
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)
Run Debian Stable. Have a few members of DOD join the Debian Security Team. Everybody wins/profits!
working smarter vs working harder?
Sorry to sound like a jerk, but isn't this what you're paid to do?
While it might be, is that any reason not to want to find a software solution to make his life easier? Heck, I thought that was what software solutions were all about? Also, have you considered it might not be his only job?
Jumpstart the tartan drive.
Find the guy's email address of who writes those specs (located somewhere on the doc, I'm sure), or it's on the server that hosts those docs, and email him and ask him where your local depository for the latest .mil approved packages are.
moox. for a new generation.
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
1) Go to redhat.com
2) Contract them for a largish consulting period and have them do a package channel for you guys
3) Dump suse
4) live happily ever after.
NO SIG
RHEL5 is getting a little stale and we often need more recent versions for various reasons; I found that downloading SRPMs from koji.fedoraproject.org and recompiling them on RHEL usually worked. The only annoying thing is that from F11 on the RPM compression has changed and RHEL can't unpack them; so I have to unpack them on my Fedora system first.
Then I just build them, sign them with our GPG key, and copy them over to our loca repo, and just run "createrepo." It's not that big a deal.
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
I've got several Linux systems, and not one of them has a lib/etc/opt/local/share directory!
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
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
Just build it off of slackware and distribute the whole thing using apt. That way, you just need to build the whole thing on one set of systems and distribute out to all the boxen you need to update/install.
Where is the "Ignorant" mod tag?
Really....
"Sorry, I can't be bothered with finding this, so I'll ask Slashdot how to do it without trying."
I would think his problem should be pretty simple. SuSE does have a package manager, right? You can uninstall the vendor package, and install your own. Voila, problem gone.
I've been known to do both the tarball method, and the source method. It's really not *that* painful to build things from source directly on the machines in question. Writing a script to log in and do something like
echo "To: me@dod.gov\nSubject: " > /tmp/somemsg /tmp/somemsg /tmp/somemsg
hostname >>
echo "somepkg\n\n\n" >>
rpm --erase somepkg >> /tmp/somemsg /usr/src/ ./configure && make && make install >> /tmp/somemsg /tmp/somemsg
cd
wget http://internal.dod.gov/srcs/somepkg.tar.gz
tar xpzf somepkg.tar.gz
cd somepkg
sendmail -t
cd .. /tmp/somemsg
rm -rf somepkg
rm somepkg.tar.gz
rm
Serious? Seriousness is well above my pay grade.
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
I think it can be adapted for Suse
http://en.wikipedia.org/wiki/M23_software_distribution_system
Holy crap, I have an answer for this.
Run ArchLinux - pacman is *perfect* for this role. Just set up a local repository and have your client image include only it. Set up a cron job on the image to do a "pacman -Syu" nightly - that's "update your package list from the repo, and install any newer versions"
Then you have a test system that you can test new versions on, and when you're ready to launch, update that package in your local repo. That night, all your clients will update to the new version.
The only thing this wouldn't address is adding packages to the systems en masse - but even this could be done in a slightly hackish way - just add the new packages as dependencies for the new version of an existing package - or better yet, roll you own PKGBUILD that installs nothing, but has all the dependencies for packages not part of the ghost image.
Arch is pretty up-to-date on package versions, and since pacman compiles from source, you can roll your own if you need something before it comes out in the official repos.
Learn about Photography Basics.
The reason that you are required to use version x.y.z or newer is because, there are security vulnerabilities with the earlier versions, and (generally speaking) if it is connected to NIPRNET and publicly facing, it is a matter of WHEN it gets hit, not IF. This is why there is a STIG, and why you need to periodically run it against your production boxes to keep them current.
:)
If you are a DoD admin, then you have been briefed on why you need to do this, I'm not going to waste time talking about it here. Failure to remain current is a reason for DISA to shut off your connection.
The scenario that there is a vulnerability, but there isn't a fix for it available yet, and you are at the mercy of volunteers to fix it, is the one of the nightmares of DoD policy makers. This is why they often argue for non open source software, because the idea is if they pay for it, then they have someone's feet they can hold to the fire(not literally, but figuratively, anyway) to get it updated! (Yes, I realize that this isn't really the case often, and closed source can take forever to close a hole, but this is the argument... facts don't always come into play when lobbyists get involved).
I always thought DoD would be the perfect place for open source software, where they could build an approved flavor of Linux, set up an approved distro site, and then hash everything to make sure that you were running version that was blessed by security to help alleviate trying to support everyone's own custom setup. Unfortunately, there are several major problems that I see with this:
1. You are beholden to the vendor of your product, and what they say they support. This is part of the bane of COTS. Not everything is developed to run on Trusted Solaris. You use whats out there in the world, not what DoD has hardened. This makes sense for budgetary purposes, but is sometimes at odds with security. "Oh, we realize that there is a vulnerability in the subsystem, but we don't support the upgrade because it breaks out system." This is also why there are so many system still running IE6.. because the java apps that were written by the tons don't work on IE7 or later (or better yet, a non M$ browser) because they don't want to update the code (or can't because the guy who cobbled the original together is no longer there, and no one else understands what the heck he did...)
2. DoD or at least the military, doesn't want to be in the development business. They only have a finite amount of bodies, which they can devote to war fighting, and don't want to waste them on support roles (try not to laugh to hard, I know they don't do a good job of this either, but that is the concept anyway). They get around this by hiring civilians and contracting support roles out, but often, this leads to enormous amounts of oversight and administrative overhead (and don't forget about the opportunity to line the PORK barrel while you are at it), and suddenly what was an inexpensive concept is not a multi-million dollar monster with a life of its own.
3. It's far easier to find vulnerabilities that it is to fix them. Also, systems have gotten so complex, and with so many components, and at times a house of cards looks more stable than a server (DCTS, I'm looking at you).
I think China might have the right idea. Mandate your own OS, and only let it be used for official purposes. This is a great idea on paper, but in practice it would run afoul of the issues mentioned above. It might work for China if they don't have a lot of modernization or a bunch of legacy systems already, that would need to be converted. They may have the willpower to want to spend the money needed to make everything happen, but I don't see the US doing this anytime soon. It is probably going to take some very painful lapses to occur before this will take place.
I apologize if I seem like for the over use of acronyms, but hey, this is about a DoD system
As far as the OP goes, you might talk to some guys who are main
I'd recommend checking out Arch, it is a bleeding edge distro that also makes recompilation quite easy. There are a lot of smart people working on it and the documentation is quite good. Arch follows the KISS principle and keeps their repositories fairly light while letting the community handle the masses of programs.
Anyway, I recommend checking it out here: http://www.archlinux.org/
Utinam me logica falsa tuam philosophiam totam suffodiant.
When working for the DoD, no matter what you problem is the their is a waiver process for it. If anything it will give you more time to figure out a solution.
Eating the brains of your enemies does not make you smarter. But it's still fun.
First rule about DoD security and stability? Don't talk about DoD security and stability. :>
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
I know of no DOD requirement for use of specific Version of software.. People confuse Local Security (SSO's) rules with DoD Wide. I would like to know which document they are reading. When you get your system accredited you have to list software and versions in the SSP/SSAA and if you upgrade you also have to do a change to the SSP/SSAA. as for back ports.. They are fine as long as you can test and show that they do what they say, and contain nothing else.. No patch is to be put on a DoD system with out vetting. the patch. your ISSO or SSO will give you guidance. if you are the admin you should have a contact for them. also DoD rules all depend on who you report to, DoDIIS, US Army, SSO Navy? DISA they all have there own rules, a lot matches. Then you have your local accrediter, or better known as the person who is responsible if your system is compermised. this person is the only one who sets version numbers, and a lot of them just say the newest with no knowledge. Disclaimer, I am a government contractor who does System Design and System Accredidation.
I have one word for, if it is a word -- STIGs! Gotta love 'em!
Setup a few servers to host the patches and pay someone to turn those newer versions into valid rpm and deb packages so they can be used to patch said systems.
Past that, the policy needs to be reviewed. If they're patching because of a physical vuln vs a remote attack then that's just plain stupid. If the system is properly secured according to TSSCI etc then it's not a huge issue to ensure upgrades for at the keyboard attacks. If you lack phys security then you have much bigger problems, any linux system can be owned in minutes if you can get your hands on it.
You ought get to work polishing your resume. Discretion is key in the defense community and blabbing about your job on Slashdot is a bad idea. For a start you should have phrased the question in a more vague manner rather than outright naming your employer. They will find out who you are and you can kiss any any access permissions goodbye in the near future.
I am becoming gerund, destroyer of verbs.
All you need to do is establish a relationship with a vendor that sells to the government and has what you think you want. Tell them up front that you want them to bid on your purchase request, however that works at your facility, and give them their product number. The purchasing department usually isn't very technical and has no way of verifying whether the item meets the specs or not so they take the vendors word for it. If anybody questions it later you can just blame the vendor for shipping the wrong item.
Remember, with the government you can only try your best then cover your ass in case someone tries to screw you.
"Meaningless!, Meaningless!" says the Teacher. "Utterly meaningless!"
"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.
"If you need to stay cutting edge, why not use a rolling distrobution such as Arch or Gentoo?"
The DoD, in general, *really* doesn't like do-it-yourself stuff. Yah, you can run Linux, but it has to be from Officially Approved vendors (Red Hat, SuSE). Only they have the secret decoder ring or whatever it is the DoD wants.
I'm sure any number of arguments against this will occur to people. You learn real quick: What you think doesn't matter for squat. You're in the army now, and they do it the army way.
(Substitute service branch of your choice.)
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
for a business model that provides a DOD-compliant distro, yes?
...the OP is impressively full of shit. Hope this helps.
I've been asking people for YEARS where Linux is used in the DoD. The answer was always the same:
Me: "Where does the DoD use Linux? I'd like to explore some different opportunities."
NCO/SNCO/Officer: "We don't. Now go run those lines."
Me: "I'm color-blind."
NCO/SNCO/Officer: "That doesn't matter."
Me: "..."
And people wonder why the Marine Corps has the lowest re-enlistment rates in the whole military.
I'm not sure how intelligent it is to publish the version numbers of all the packages you use anyhow. By publishing them someone can now easily look up the vunerabilities and attack. Its one thing to be on a old version, but its another to tell someone that you are.
Am I lying when I tell you that im telling the truth? Or am I telling the truth when I say that Im lying?
Most likely, the mandate for the latest major versions of packages comes from STIG. The STIG is a guideline, and more often than not, requires an explanation as to why you have chosen not to comply. I've been able to get around the broken STIG assumption that only the latest major version of a package contains the required security fixes by writing up a vulnerability assessment that includes the patch-level of the package from the vendor (RedHat in my case), and the changelog of that patch that almost always includes the CVE for which the fix was provided.
The intent of the STIG issue is to close a security hole, *NOT* to force you to dangerously track the very latest major/minor version of a package. If you can show that you are closing security issues by suing the latest version from your vendor, then you are complying with the goal of the STIG.
I've found the NSA hardening guides, on what used to be called the SNAC, pretty useful: http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml#linux2
Go with windows! Yep, sooner or later year of Windows on desktop will come and even that woody heads in gov will have to adapt
God's gift to chicks