[Info-vax] New VSI Roadmap (yipee!)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Simon Clubley
> Sent: 01-Mar-15 8:18 AM
> To: info-vax at info-vax.com
> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
> 
> On 2015-02-28, Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> wrote:
> > On 2015-02-28 15:57:39 +0000, Kerry Main said:
> >
> >> Now, if there had not been such a significant increase in the OS
> >> instances, the monthly security patches might have been more
> >> manageable, but the culture of 1 or 2 bus apps per OS instance that
> >> was established in the distributed days of commodity OS's (and
> >> significantly boosted by the likes of VMware) has resulted in the
> >> OPS groups throwing up their hands and have adopted
> >> patch-n-pray.
> >
> > Not having patches and not having updates concerns me as much ? if
> not
> > more ? than having patches to apply.  VMS just is not that secure.
> 
> Congratulations Hoff, you got it in one.
> 
> About a year or two ago when Kerry was in full flow about his 10-40
> patches a month, I did an analysis of the RHEL patches for a month
> (and posted the results to comp.os.vms).
> 
> What I found was that for many of the patches, they either covered
> application level software issues which should have been investigated
> for VMS as well (PHP, Java, etc) or involved functionality which
> simply doesn't exist on VMS.
> 
> For that month's worth of data, the number of core Linux issues with
> comparable VMS core functionality were _way_ under that 10-40
> patches
> per month number Kerry likes to use.
> 
> Simon.
> 

Simon - not sure if you work in a med-large Operations shop, but when 
you have hundreds+ of OS instances to harden, someone has to review 
these large number of security patches every month and match them
against those hundreds of OS instances. Not just the kernel patches,
but also to all those Apps running in those hundreds of OS instances.
And of course, no one has a really std environment, so you get multiple
Versions of Apps, Java, PHP levels etc.

If using best practices, then any kernel or potentially serious patch 
should be tested against important apps before rolling out. The kernel
security patches need a reboot, so downtime needs to be examined.

In addition, many of the descriptions of the security patches are on
purpose and understandably vague (no one wants to give bad guys to
much of a clue), so most shops would choose to install just in case.

You can argue some of the functionality is not on OpenVMS, but that
is a different discussion than what is real today and what different OPS 
shops have to deal with.  A missing feature may not be important to a
shop or they may have found other ways to implement the same or 
similar functionality e.g. using firewall rules for consistency across all
systems vs individual host based mechanisms.

And just to correct your point, many of the single line references on 
the Red Hat security web site are actually "bundles" of patches, so
the number is likely much higher.

And just to ensure there is no confusion, I am not saying the OpenVMS
environment does not need new security features or better ways of
responding to patches. Now that OpenVMS has a new handler, I 
strongly suspect the future will indeed be much more rosier.

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com