[Info-vax] OpenVMS versus Windows/GE Telemetry Control Systems.

[John Wallace]

On Jan 15, 8:10 pm, Bob Gezelter <gezel... at rlgsc.com> wrote:
> On Tuesday, January 15, 2013 1:46:39 PM UTC-5, John Wallace wrote:
> > On Jan 15, 5:57 pm, Simon Clubley <clubley at remove_me.eisner.decus.org-
>
> > Earth.UFP> wrote:
>
> > > On 2013-01-15, David Froble <da... at tsoft-inc.com> wrote:
>
> > > > As for the case of the original poster, the Alpha systems are running
>
> > > > today, and will continue to run until something breaks.  Given the
>
> > > > history of DEC hardware, it should normally be expected to run for a
>
> > > > long time yet.  Individual pieces can and do break, and then it's a
>
> > > > question of whether there is any recourse to fixing or replacing the
>
> > > > failed equipment.  In most cases, fixing or replacing is far less costly
>
> > > > than a migration of the system to something else.  In business decisions
>
> > > > should be based on a cost / benefit ratio.
>
> > > I wonder why people only consider hardware breaking instead of also
>
> > > considering software breaking.
>
> > > In this Internet connected world, software can break just as hard as
>
> > > hardware when a security exploit is discovered and can be a _lot_ harder
>
> > > to fix than a simple hardware failure.
>
> > > If you have a hardware failure, you can just replace your board or
>
> > > component and resume normal service. OTOH, if someone finds a protocol
>
> > > vulnerability or stack/server coding error in the software you are
>
> > > running, you are dead in the water until either you find a workaround
>
> > > or your code base is fixed either by you or your vendor.
>
> > > Current mainstream platforms may have issues, but you can have more
>
> > > confidence that either a workaround or fix will be available in short
>
> > > order for any active exploit that makes it into the public domain for
>
> > > those platforms.
>
> > > I've gone through several cycles of getting Internet related components
>
> > > fixed under VMS and the fixes took a lot longer than I would be comfortable
>
> > > with if the problem in question had been a active exploit.
>
> > > Simon.
>
> > > --
>
> > > Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
>
> > > Microsoft: Bringing you 1980s technology to a 21st century world
>
> > Maybe.
>
> > Stuxnet was quietly working its way around Window boxes for a long
>
> > while (maybe a year?) before it got serious attention. Ignorance is
>
> > not necessarily bliss. If folks haven't yet looked into Stuxnet or its
>
> > successors (eg Duqu), there's no time like the present, and the
>
> > Wikipedia article on Stuxnet isn't a bad start, although for further
>
> > reading I'd recommend Ralph Langner and maybe Symantec.
>
> Simon,
>
> I note that my published recommendation for nearly twenty years has been to "air-gap" process control systems from the general corporate network as well as the public Internet [citation: Computer Security Handbook, 3rd Edition].
>
> - Bob Gezelter,http://www.rlgsc.com

For more than twenty years, major computer vendors have been talking
about "integrating the enterprise" (the theme for DECworld 88, I
believe) and doubtless similar themes elsewhere.

True real time automation often needs to interact with some of the
'corporate' systems somehow. Without that interaction, a lot of the
benefits may be lost. So that has to be a rather carefully managed
connection.

Even when there isn't an obvious connection to the IT-'managed'
network, routine maintenance of the automation side of things will
often involve connection of a Window box (which may not even look like
a PC/laptop, it may be called a "programming panel" or similar).
Connect this infested Window box to the automation LAN, and the airgap
is irrelevant. That's not a hypothetical example, that's (part of) the
story of Stuxnet (as Hoff already noted).