The sad part is that this is barely news in WV. Oh, there have been numerous lawsuits over the years challenging each of the companies mentioned above for various abuses, often with commercials and mailers asking you to contact Dewey, Cheatum, and Howe, attorneys at law or some such nonsense. I moved away six years ago and I still get mailers today for class-action suits from my time there.

I played baseball at the parks across Viscose Road from the industrial park mentioned in the story. My mom worked in Nitro along that same road where there was an EPA Superfund cleanup site for Fike Chemical. They found all kinds of junk there, including hydrogen cyanide and methanethiol. There was also a tremendous tire warehouse fire about five years ago near the industrial park mentioned in the story. The story goes on and on, and has ever since the nitrocellulose plant was built in 1917 for World War I.

It's unfortunate, but coal and chemicals (and medical services for those dealing with coal and chemicals) are the only kind of work that is generally available in that area. It provided a good living for the time, but left a pretty awful legacy now that those jobs are packing up and leaving.

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.