nate wrote:
Ross S. W. Walker wrote:
The agencies don't know what security backports vendor XYZ has implemented and frankly they don't care. All they have is a list of minimum version numbers that software must be at in order for it to be deemed "compliant".
So check the actual version number of the package. Using a remote network software scanner to detect security problems based on banner strings provided by the network software is nothing more than a false sense of security.
I'm not worried about myself. In a regulated environment the agencies do not trust corporations will honestly test their controls, so they have outside auditing firms and agencies test them for you and it is often these outside firms or agencies that take unreasonable or uneducated stances and often times there is very little you can do. When the FDIC says jump your correct response should be "How high?".
I think we will start seeing this in the PCI and HIPA compliance regulations first, but I wouldn't be surprised if it leaks out into GLBA and other regulations over time.
The scanning vendors will be forced to fix their products. It's perfectly acceptable, and preferred behavior to backport patches. Just look at the recent Samba thread here for a good reason why backporting is good. I'd be mightily pissed if RHEL or CentOS switched a version out from under me which caused breakage. I honestly cannot believe that RHEL did that for Samba. If anything introduce a new ALTERNATE package that has the incompatible changes in it and allow users to choose between that one and the original for their systems. That's just me though. Fortunately I don't really use Samba.
I agree whole heartily. It would go a long way though if Redhat provided independent certification of their products under these compliance banners.
Does anybody know if such a thing exists now?
That way with the certification in hand and proof that the servers are kept up to date one can keep the auditors at bay.
I think it will be these compliance issues that may force upstream to change their strategy otherwise I can see this being a roadblock to RHEL/CentOS adoption in these industries in the future.
I highly doubt it. It'll be the scanning companies that will have to change. RHEL/CentOS are not the only ones that backport fixes. Really they need to have a database of package names and versions, and a set of scripts to run on the various servers to compare the versions with their "approved" list. After all it's not easy to remotely determine the kernel version.
You know that is if the auditing firms and agencies actually use scanning software, or if they ask for a package listing and go through that list by hand.
We are talking about the US government here.
Network scanning is OK for some things, especially if you are attempting the actual security vulnerability rather than just assuming it has or does not have it based on the version.
Take Oracle for example, pretty expensive piece of software. Lots of security holes in it. I'm not a DBA so I looked up how to find what patches are installed, and as far as I can tell you cannot determine those patches remotely, you need to run a command on the local host.
My production oracle servers(10.2.0.3) currently have 34 patches installed. And the version string did not change.
Installed Top-level Products (3):
Oracle Database 10g 10.2.0.1.0 Oracle Database 10g Release 2 Patch Set 1 10.2.0.2.0 Oracle Database 10g Release 2 Patch Set 2 10.2.0.3.0 There are 3 products installed in this Oracle Home.
Interim patches (34) : [..] (snip)
And guess what? all 34 patches are security related. I have 8 more patches to get installed soon as well.
Yes of course the software needs to be kept up to date that goes without saying. One can only hope that with a certificate from Redhat that they keep software up to date with security fixes within a reasonable time frame by backporting them can be had.
Then there is the whole convincing these firms and agencies that since CentOS is a duplication of Redhat's system it is therefore certified by the laws of transitivity, but who knows if they will buy it...
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.