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

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman
> Sent: 01-Mar-15 10:03 AM
> To: info-vax at info-vax.com
> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
> 
> On 2015-03-01 02:06:32 +0000, Kerry Main said:
> 
> > Imho, it should be possible to release a well architected & well-tested
> >
> > commodity OS product in the future (ok, OpenVMS) which does not
> >
> > require many monthly security patches.
> 
> Outside of devops, security beyond that required by regulation is
> seldom interesting.   Worse, if security gets in the way, it gets
> bypassed or disabled.

Do not agree. In most companies today, security folks have the final
say. Bypassing and/or disabling security mechanisms is grounds for not
only dismissal, but also potentially criminal persecution if the company 
is impacted in a big way.

>   seL4 and selinux aside, and the occasional
> marketing of some security features to the more technical folks,
> security is not typically a central feature in a product sale.   For
> many folks, if it's got AV, it's good enough.  Even if the AV provides
> the equivalent security of waving a rubber chicken over the box, using
> the specific counter-clockwise waving procedure described in appendix
> A.

I agree that security has not been a factor in product sales in the past.

However, there is a fast growing awareness that security needs to be
integrated as part of the overall solution and not just tacked on at the
end. 

> 
> From what I've seen of it, security is third or fourth or fifth or
> lower on the usual pick list for a volume platform, after data and
> application compatibility, and affordability, and familiarity, and
> ease-of-use, and (yes) perception.
> 
> > Can you imagine bringing your Toyota or Ford car in every month to
> have
> > fixes applied so you can use this product safely?
> 
> If I paid little or nothing for the car as compared with the resources
> that went into building and shipping it, yes.  I'd expect ads, and
> specific Toyota fuel and Ford fuel requirements, and that I'd need to
> purchase my travel mugs from sketchy street booths or from the
> manufacturer, and that driving at highway speeds might require an
> in-dash purchase, too.
> 

Most companies using RH Linux are very aware Linux is not free. Yes,
they have no upfront CAPEX impacting licenses, but the monthly 
support contracts are per core based and when there are hundreds 
of OS instances .. the cost to OPEX (operations) budgets is expensive.

[Snip..]

> 
> It's unpleasant, but is entirely sustainable, until there is a better
> alternative that still gets the job done.  Even a better alternative
> still involves patches.  Ignoring that VMS lacks the necessary APIs and
> the applications and the compatibility and the distributed management
> tools and the deployment tools and the x86-64 support and the
> compatibility with the existing staff expectations, VMS has already
> been in the patch-of-the-month club for anybody using OpenSSL, so
> you're right back into the quagmire.   Worse, Apache SSL from the SWS
> V2.2 update 2 kit is 0.9.8w from 23-Apr-2012, and that's rather far
> back.  Again, I see no solution here.
> 

Yes, there have been a few revisions of the SSL patches by HP. No one
here is saying HP has done a great job managing patches (security or
bug fixes). However, the scale is mountains vs molehills.

> > I also do not accept that as a platform gets more popular it
> automatically
> >
> > means more security issues magically appear. This is the banks vs.
> corner
> >
> > stores analogy.
> 
> We'll disagree there, then — more complex configurations and more
> pieces and parts means more vulnerabilities, and — even with a good
> team — scheduling and market pressures and increasingly complex
> software can and variously does lead to bugs, too.  Maybe not all that
> many bugs in the classic VMS kernel, but there's a whole lot of
> open-source code around, a whole lot of add-on (privileged) code, and
> there'll be more of it all on VMS in time, should VMS become
> ubiquitous.    VMS was built for an environment were everything
> installed was considered trusted.  The mechanisms for VMS signed kits
> are the first break from that trust, and there'll need to be much more
> suspicion about what's installed and running in the future.
> 
> This effort also likely means adding UAC / Gatekeeper defenses, and
> jails or sandboxes or Qubes capabilities to keep the applications
> relatively contained, and ASLR and canaries, and developer-signed
> application distributions, potentially an application store, and better
> patch notification and secure and encrypted patch distribution and
> easier installation mechanisms, and configurable firewalls, and
> distributed event logging, and encrypted cluster transports and the
> retirement of DECnet and telnet and ftp, and encrypted SNMPv3
> management, and authenticated network connections, faster
> mechanisms
> for porting updates to OpenSSL and Apache and core open-source tools,
> updates to compilers that flag (for instance) strlen() and strcpy() and
> strcat() and such, and central and per-user certificate storage, and
> other security-related features, and whatever other useful
> defensive-security ideas arise in the next five or ten years while VSI
> is beavering away on the port and on these and more likely on other and
> more-directly-revenue-producing projects.  Even with a good
> development
> team, some of these security upgrades will be found to have
> security-relevant bugs, too.
> 
> TL;DR: Give me a viable alternative to the patch-of-the-month club, and
> I'm in.
> 

Bottom line - No matter what new features are added, the OpenVMS 
customer community would simply revolt if OpenVMS were to evolve 
to 40+ (ok, let's say "many") security patches per month. Most would 
say throw out the new features or third party SW.

So, creative thinking needs to be done to add new features while still
maintaining OpenVMS's traditional integrated security focus.

Regards,

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

Kerry dot main at backtothefutureit dot com