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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
