On 1 August 2012 23:14, Alan Cox <a...@lxorguk.ukuu.org.uk> wrote: > The question is > > 'What CVE numbers are the flaws being logged and does your vendor release > have those fixed according to the changelog and their security statements' > > Don't do security by version numbers, it's broken and anybody who simply > says "oh you've got release X it must be busted" isn't properly trained > to use the tools IMHO and shouldn't be doing the job. Security is > important, doing it right is important. Learning to do the basics right is > not that hard.
Most certainly. I've been fighting this in a previous life already. Unfortunately the distributors start this by reporting the packages from the "consumer grade" distribution that have the fix for the CVE included. That's what gets recorded in the databases and appears to be what security officers exchange in their private discussions. If the company has a patch policy at all, this is typically the release numbers you're ranked on. Following the model of US law enforcement style, merely questioning the validity of the policy will make you the main target of their concern... So we had to "reverse engineer" every patch request that used terms like "if installed, must have openssh-5.2p1-9.1 or higher" to dig up the CVE that they were after, see whether the enterprise distribution comes up in a few days with a new level of openssh maybe and see whether openssh-5.1p1-41.51.1 mentions the same vulnaribility to be fixed. This was a manual process because often the enterprise version was not impacted and did not get a new package. With that information we would request an excemption from the patch date requirement... Tedious is an understatement. A big win was to get rid of all extra software you don't need, as discussed in the thread. Combined with a strict software management policy that does not allow the local admin to install midnight commander just becase he likes it... We also started to build our own security package that would carry the required levels as dependency, so your security scan was reduced to just checking the level of that package. Upgrade of that package would pull in the patches for openssh etc. > Enterprise vendors add fixes to old versions to minise the risk of other > destabilizing changes. That is much of their entire business model. Often you will even find that the vulnerability was introduced in a level later than what we have in the enterprise distribution, so there may never be an update that fixes that CVE for the enterprise distro. The enterprise distributors could make our life simpler with a security package as mentioned. You'd get an update of that package every month or so, pulling in any updates to packages that fix reported vulnerabilties, if any. So rpm -U of the latest update would show me which real packages are affected (and plan an outage if needed). The company security policy could be as simple that for certain class of servers you need to have that package installed within 2 months after it was released. Very simple to check. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
