On 8/4/2022 9:13 PM, Kerry Main wrote:
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj via Info-vax
>> Sent: August-04-22 9:28 PM

>> It seems very plausible that DEC, to some extent Compaq and HP, US DoD,
>> NSA and a bunch of big companies that relied (or still
>> relying) on VMS did extensive security testing. That makes sense.
>>
>> But it does not seem plausible that they tested VMS to the same extent as
>> Linux and Windows are beeing tested today. The money and the people was
>> not there (US DoD and NSA may have had the money, but they had many
>> other priorities).
>>
>> The number of people involved in security research today is huge. I don't
>> know how many, but it must be in the tens of thousands of people.
>>
>> But no I do not expect those tens of thousands to get any interest in VMS
>> due to the arrival of VMS x86-64 or whatever VSI web site contain. The
>> money is still not there.
>
> re: past Customers putting OpenVMS through the ringer from a security perspective..
>
> In approx. 2005 timeframe, the Shanghai Stock Exchange dropped their
> previous mission critical trading platform for what they called their
> "Next Generation" trading platform that was based on an OpenVMS
> Integrity based multi-site cluster. Disclosure - I do not know if
> this platform is still in place or not. >
> Btw, at the time, some predicted the Shanghai Stock Exchange might
> eventually replace the NYSE in terms of WW importance. >
> Does anyone think this next generation trading platform based on
> OpenVMS Integrity was not put through many, many security scenarios
> before this final decision was made?
It seems highly likely that they both reviewed others work
and did their own work.

But it is still a tiny fraction of what the most popular
platforms get tested.

Arne

On 08/04/22 00:11, gah4 wrote:
> On Wednesday, August 3, 2022 at 4:03:31 PM UTC-7, chris wrote:
>
> (snip)
>
>> That may be true, but there are literally decades of hacker experience
>> with X86, because of the ubiquity of the hardware and operating
>> systems, windows, for example. In comparison, how
>> often do we hear of destructive and expensive hacks of power, sparc or
>> mainframe systems ?. Yes, the cpu arch is only one brick in a security
>> model, but a pretty substantial one given the potential for hacking
>> with X86. It means that extra work is needed at all levels of os and
>> application design...
>
> I was working with Sun machines around the time of the SunOS to
> Solaris transition. Early in the Solaris years, there were more attacks
> on Solaris than SunOS, second only to Windows.

Been involved with Sun machines since Sun3 and still run Sparc machines
here for things like nfs server. It was a much more gentle world back
then and suspect that most hacking was done as a a technical challenge,
not for commercial gain. Now, hacking is done on an industrial scale,
including state actors with essentially limitless resources. Serious
money and potentially global political repercussions. With hidden
and undocumented management processors, not real way to verify anything.

Embedded background here and if I can't have full visibility from
application right down to bare metal, it can only be suspect
from a security pov. Trust but verify should apply, but no longer
possible for anything with hidden functionality. Hence my quite
reasonable caution over anything X86...

Chris

>
> It seems that, at the time, Solaris was popular for web servers,
> and so were interesting to hackers.
>
> There are some favorite tricks to get x86 systems to write data onto
> the stack, and then execute it. There are now hardware features to
> make that harder. I don't know if the same tricks would work for
> other x86 OS, but in any case, would need to exploit OS features
> once the code was running.
>
>
>
>

On 08/05/22 21:38, Dan Cross wrote:
> In article<tcj1gk$34t5l$1@dont-email.me>,
> Simon Clubley<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2022-08-04, Arne Vajhøj<arne@vajhoej.dk> wrote:
>>> On 8/4/2022 8:29 AM, Simon Clubley wrote:
>>>>
>>>> Well, in fairness to Chris, while he clearly has an ideological dislike
>>>> for x86-64 for whatever reasons, this is also the architecture that has
>>>> all the Intel Management Engine and other management stuff running on
>>>> modern versions of that architecture.
>>>>
>>>> Stuff that runs underneath your operating system and can't be switched off.
>>>
>>> ME are not really ISA specific.
>>>
>>> ME is AFAIK only available for x86-64 chipsets.
>>>
>>
>> Unfortunately, AMD has its own version as well: :-(
>>
>> https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor
>
> Yup. At the moment, not much you can do about the PSP, though
> once it's trained DRAM and loaded the code that runs at the x86
> reset vector, you can pretty much turn it off and ignore it.
>
> - Dan C.
>

Have a look at the Wiki article on the Intel Management Engine,
if you want to spoil your day. Just a snippet, but can have
visibility of all network traffic before it even reaches the host
os network stack.

https://en.wikipedia.org/wiki/Intel_Management_Engine

You have to assume that no machine can be made really secure and
plan accordingly...

Chris

On 08/05/22 22:01, Dan Cross wrote:
> In article<mailman.4.1659713637.674.info-vax_rbnsn.com@rbnsn.com>,
> Kerry Main<kemain.nospam@gmail.com> wrote:
>> [snip]
>> So, just because you found a hole (that was subsequently fixed), you infer
>> there are still major issues with "how many more did they miss?"
>
> Yes, absolutely. Of course. We know from decades of software
> engineering research that the presence of bugs tends to indicate
> more bugs in the affected system; the exact classification of
> those bugs is immaterial.
>
>> However, the same can be stated for every OS platform.
>>
>> History has shown that every OS platform will eventually have security
>> issues that will need to be fixed. No OS platform is 100% secure.
>>
>> None.
>
> Yes. Precisely why people _should_ audit VMS. Either they find
> bugs that are then fixed, or they don't. In either case, you've
> learned something useful.
>
>> As far as "relying on those stock exchange audits to say that VMS has been
>> audited" ...
>>
>> I never stated this. I simply provided this as one example of a highly
>> mission critical Customer environment that, in the 2005 timeframe, did
>> thoroughly analyze the OpenVMS platform.
>>
>> After this review, the Stock Exchange dropped their old HP-UX trading
>> platform and adopted OpenVMS Integrity in a active-active multi-site config
>> as their Next Generation trading platform.
>
> That's great. But that doesn't mean that there are not security
> bugs lurking in VMS. Entirely new categories of security bugs
> have been discovered since 2005.
>
> - Dan C.
>

I'm well out of date now, but didn't VMS win the highest security
classification for us government work ?. If so, would assume that
it would have been thrashed to bits by both dec and government
organisations to win that approval ?...

Chris

On 8/5/2022 8:00 PM, chris wrote:
> I'm well out of date now, but didn't VMS win the highest security
> classification for us government work ?.

I believe VMS was classified C2 and SEVMS was classified B1 where
the order from most to least secure is A1-B3-B2-B1-C2-C1-D.

30-35 years ago.

> If so, would assume that
> it would have been thrashed to bits by both dec and government
> organisations to win that approval ?...

After the standards at that time: yes.

After todays standards: not so much.

Arne

On 8/5/2022 3:46 PM, Scott Dorsey wrote:
> chris <chris-nospam@tridac.net> wrote:
>> The problem with that, of course, is that the internals are
>> not fully disclosed, so cannot be fully secured. Should be
>> some way to disable it, but no way to tell how it interacts
>> with the rest of the system. A glaring security hole, but
>> no doubt some government agencies have the full story and
>> how to compromise it...
>
> The x86_64 architecture really isn't documented inside at all, so things like
> the management processor which starts up and initializes the CPU (and which
> appears to be able to do a lot more) and the firmware built into that
> management processor are pretty much undocumented. Some folks have managed
> to reverse-engineer the 8051-like management engine in 1980s x86 processors
> but everyone suspects that we have come a long way.

Supposedly ME before version 11 was a ARC CPU (RISC) running
ThreadX while ME from version 11 is a Quark CPU (32 bit x86)
running Minix.

Arne

On 8/4/2022 11:10 PM, David Goodwin wrote:
> On Friday, August 5, 2022 at 11:31:51 AM UTC+12, Arne Vajhøj wrote:
>> On 8/4/2022 10:10 AM, Dan Cross wrote:
>>> In article <tcc5ih$ues$1...@news.misty.com>,
>>> Johnny Billquist <b...@softjar.se> wrote:
>>>> On 2022-08-02 16:33, Dan Cross wrote:
>>>>> It boggles my mind that people think that an organization that
>>>>> has explicitly declined to work with the VAX (for the very valid
>>>>> reasons mentioned elsewhere in this thread) would care if a few
>>>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>>>> issue licenses for anyway.
>>>>>
>>>>> Maybe those people have the inside track with someone at at VSI
>>>>> who has told them that this is as big a deal as they are making
>>>>> it out to be, but I find that doubtful.
>>>>
>>>> I doubt it's the talking point of the day for VSI. But never the less,
>>>> there is a point in observing how people behave in similar situations to
>>>> deduce how they might behave elsewhere.
>>>>
>>>> Bill did make a good point about the non-existence of hobbyist program
>>>> for the PDP-11 software, which allegedly is because people were
>>>> misbehaving. And VSI might look at how people behave around the VAX and
>>>> decide how they want to continue hobbyist stuff for the platforms they
>>>> have made releases for.
>>>
>>> The bottom line is that absent some definitive statement from
>>> VSI, this is all speculation.
>> True.
>>
>> But the day it is no longer speculation then it is too late.
>>
>> It is a risk.
>>
>> You could certainly argue that people willing to take a risk on
>> their own behalf should be allowed to do so, but here the risk applies
>> to the entire community.
>>
>> So people are not going to the casino and betting just their
>> own savings - people are going to the casino and betting their
>> own plus everybody elses savings.
>
> Its not a risk.

Of course it is.

It is a negative outcome with a probability greater than zero
and less than one.

That is what is called a risk.

> The community license is necessary for the viability
> of OpenVMS as a platform.

Given that VMS existed fine for many years without one then
that claim seems questionable.

I believe that the CL is beneficial. But I find it difficult to
see it as necessary.

The CL program is not used by young people wanting to learn
VMS - it is used by people that used VMS or still use
VMS professionally.

The main benefit is probably the limited open source
development and test being done on CL systems.

> If VSI takes it away that's them saying
> they see no future for OpenVMS

No.

It would be them saying that they don't see the benefits
cover the cost associated with the program.

> and therefore no need to increase
> the number of people with OpenVMS skills.

I don't think the CL program has increased the number of people
with VMS skills. There may be a few, but you could probably
invite them all for coffee in your dining room.

Arne

On 06/08/2022 01:00, chris wrote:
> On 08/05/22 22:01, Dan Cross wrote:
>> In article<mailman.4.1659713637.674.info-vax_rbnsn.com@rbnsn.com>,
>> Kerry Main<kemain.nospam@gmail.com>  wrote:
>>> [snip]
>>> So, just because you found a hole (that was subsequently fixed), you
>>> infer
>>> there are still major issues with "how many more did they miss?"
>>
>> Yes, absolutely.  Of course.  We know from decades of software
>> engineering research that the presence of bugs tends to indicate
>> more bugs in the affected system; the exact classification of
>> those bugs is immaterial.
>>
>>> However, the same can be stated for every OS platform.
>>>
>>> History has shown that every OS platform will eventually have security
>>> issues that will need to be fixed. No OS platform is 100% secure.
>>>
>>> None.
>>
>> Yes.  Precisely why people _should_ audit VMS.  Either they find
>> bugs that are then fixed, or they don't.  In either case, you've
>> learned something useful.
>>
>>> As far as "relying on those stock exchange audits to say that VMS has
>>> been
>>> audited" ...
>>>
>>> I never stated this. I simply provided this as one example of a highly
>>> mission critical Customer environment that, in the 2005 timeframe, did
>>> thoroughly analyze the OpenVMS platform.
>>>
>>> After this review, the Stock Exchange dropped their old HP-UX trading
>>> platform and adopted OpenVMS Integrity in a active-active multi-site
>>> config
>>> as their Next Generation trading platform.
>>
>> That's great.  But that doesn't mean that there are not security
>> bugs lurking in VMS.  Entirely new categories of security bugs
>> have been discovered since 2005.
>>
>>     - Dan C.
>>
>
> I'm well out of date now, but didn't VMS win the highest security
> classification for us government work ?. If so, would assume that
> it would have been thrashed to bits by both dec and government
> organisations to win that approval ?...

It was evaluated against the threats of the day using the tools of the
day and the landscape of the day. It would fall at the first hurdle in
today's field.

The world has moved on. Simple example, encryption algorithms that were
considered secure when VMS was evaluated are no longer considered
secure. These days data must be encrypted when at rest.

Read a few recent IBM announcements about the encryption algorithms they
are adding to zOS the modern equivalent to MVS to get through current
security requirments.

Windows/NT also had similar security clearances, yet Digital (UK)
produced a hardened version of Windows/NT that had enhanced network
security (Secure/NT) and a hard disk encryption tool (Kilgetty) for the
UK government, so even in the day it was recognised that security
evaluations were incomplete.

Saying VMS is secure is like saying its safe to use a 1950's car on
todays roads. Having once gone cheap and hired a compact to get from
Newark to the Vintage Computer Festival at Wall so took the Jersey
Turnpike, when I struggled to reach up to the toll booths to drop my
dollar in, there is no way would I drive use a 1950s car with rod
brakes, lap seat belts, no ABS etc. on todays roads as an everyday car.

Nor would I use my VLC as an everyday tool for internet access. Its old
enough to probably not be a target, but its not a pleasant experience.

>
> Chris
>

Dave

On 8/5/22 20:00, chris wrote:
> On 08/05/22 22:01, Dan Cross wrote:
>> In article<mailman.4.1659713637.674.info-vax_rbnsn.com@rbnsn.com>,
>> Kerry Main<kemain.nospam@gmail.com>  wrote:
>>> [snip]
>>> So, just because you found a hole (that was subsequently fixed), you
>>> infer
>>> there are still major issues with "how many more did they miss?"
>>
>> Yes, absolutely.  Of course.  We know from decades of software
>> engineering research that the presence of bugs tends to indicate
>> more bugs in the affected system; the exact classification of
>> those bugs is immaterial.
>>
>>> However, the same can be stated for every OS platform.
>>>
>>> History has shown that every OS platform will eventually have security
>>> issues that will need to be fixed. No OS platform is 100% secure.
>>>
>>> None.
>>
>> Yes.  Precisely why people _should_ audit VMS.  Either they find
>> bugs that are then fixed, or they don't.  In either case, you've
>> learned something useful.
>>
>>> As far as "relying on those stock exchange audits to say that VMS has
>>> been
>>> audited" ...
>>>
>>> I never stated this. I simply provided this as one example of a highly
>>> mission critical Customer environment that, in the 2005 timeframe, did
>>> thoroughly analyze the OpenVMS platform.
>>>
>>> After this review, the Stock Exchange dropped their old HP-UX trading
>>> platform and adopted OpenVMS Integrity in a active-active multi-site
>>> config
>>> as their Next Generation trading platform.
>>
>> That's great.  But that doesn't mean that there are not security
>> bugs lurking in VMS.  Entirely new categories of security bugs
>> have been discovered since 2005.
>>
>>     - Dan C.
>>
>
> I'm well out of date now, but didn't VMS win the highest security
> classification for us government work ?. If so, would assume that
> it would have been thrashed to bits by both dec and government
> organisations to win that approval ?...
>

Times and technology change. The "Orange Book" is long gone.
And DOD (ie DISA) stopped looking at VMS in 2009 when I was
there. At that point the VMS STIGS and Checklists were very
out of date and an offer to update them was met with a "don't
bother, not interested" reply.

bill

On 2022-08-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/5/2022 8:00 PM, chris wrote:
>> I'm well out of date now, but didn't VMS win the highest security
>> classification for us government work ?.
>
> I believe VMS was classified C2 and SEVMS was classified B1 where
> the order from most to least secure is A1-B3-B2-B1-C2-C1-D.
>

And SEVMS doesn't even exist any more.

Judging by the documentation I was able to find on it, it also did
far less than what SELinux is capable of doing.

For example, I don't remember any real integration with TCP/IP, unlike
with SELinux, where you have _very_ tight control over what you allow
to happen with TCP/IP based services.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Saturday, August 6, 2022 at 1:02:11 AM UTC-7, David Wade wrote:
> The world has moved on. Simple example, encryption algorithms that were
> considered secure when VMS was evaluated are no longer considered
> secure. These days data must be encrypted when at rest.
>
> Read a few recent IBM announcements about the encryption algorithms they
> are adding to zOS the modern equivalent to MVS to get through current
> security requirments.
>
> Windows/NT also had similar security clearances, yet Digital (UK)
> produced a hardened version of Windows/NT that had enhanced network
> security (Secure/NT) and a hard disk encryption tool (Kilgetty) for the
> UK government, so even in the day it was recognised that security
> evaluations were incomplete.
>
> Saying VMS is secure is like saying its safe to use a 1950's car on
> todays roads.

These points are critical. No one is saying DEC didn't take security seriously when they designed and built VAX/VMS; their assumptions were based on the state of information security in the late 1970s and early 1980s. Many of those same engineers designed Windows NT's security features, incorporating learning along the way.

There are entire classes of security attacks that had not been invented in 1977, or 1989, or in 2005, or even in 2020. Protecting an operating system requires dynamic, continuous investments and bug fixes, participation in responsible reporting, and realism about the capabilities of state actors and criminal enterprises.

The slow pace of investment in OpenVMS likely helps its security posture by reducing its attack surfaces. How many old versions of VMS are running in production, with out of date services or open source components that are missing years of security patches? How seriously did the sustained engineering teams at HP take threat modelling, penetration testing, and service hardening? How many of VSI's limited engineering resources go into modern security practices? Hard to say.

It's unwise to assume that the best practices that DEC displayed in the 1980s are still relevant in protecting customers running OpenVMS in 2022.

> > ME are not really ISA specific.
> >
> > ME is AFAIK only available for x86-64 chipsets.
> >
> Unfortunately, AMD has its own version as well: :-(

Most modern CPU implementations have management processors, co-processors, or supervisory processors running with high levels of privilege using embedded operating systems of their own. You see it on modern MIPS implementations, nearly every modern ARM SOC, POWER, as well as Intel and AMD. They're usually undocumented and ripe targets for security attacks or supply chain vulnerabilities.

Moreover, side-channel attacks like Spectre and Meltdown were discovered on nearly every modern CPU implementation, and variants likely exist in every implementation of branch prediction and out-of-order execution over the past couple of decades; I would bet money that they exist on later generations of Alpha, for instance.

On 08/10/22 05:10, jimc...@gmail.com wrote:
> On Saturday, August 6, 2022 at 1:02:11 AM UTC-7, David Wade wrote:
>> The world has moved on. Simple example, encryption algorithms that were
>> considered secure when VMS was evaluated are no longer considered
>> secure. These days data must be encrypted when at rest.
>>
>> Read a few recent IBM announcements about the encryption algorithms they
>> are adding to zOS the modern equivalent to MVS to get through current
>> security requirments.
>>
>> Windows/NT also had similar security clearances, yet Digital (UK)
>> produced a hardened version of Windows/NT that had enhanced network
>> security (Secure/NT) and a hard disk encryption tool (Kilgetty) for the
>> UK government, so even in the day it was recognised that security
>> evaluations were incomplete.
>>
>> Saying VMS is secure is like saying its safe to use a 1950's car on
>> todays roads.
>
> These points are critical. No one is saying DEC didn't take security seriously when they designed and built VAX/VMS; their assumptions were based on the state of information security in the late 1970s and early 1980s. Many of those same engineers designed Windows NT's security features, incorporating learning along the way.
>
> There are entire classes of security attacks that had not been invented in 1977, or 1989, or in 2005, or even in 2020. Protecting an operating system requires dynamic, continuous investments and bug fixes, participation in responsible reporting, and realism about the capabilities of state actors and criminal enterprises.
>
> The slow pace of investment in OpenVMS likely helps its security posture by reducing its attack surfaces. How many old versions of VMS are running in production, with out of date services or open source components that are missing years of security patches? How seriously did the sustained engineering teams at HP take threat modelling, penetration testing, and service hardening? How many of VSI's limited engineering resources go into modern security practices? Hard to say.
>
> It's unwise to assume that the best practices that DEC displayed in the 1980s are still relevant in protecting customers running OpenVMS in 2022.
>
>
>
>
I think we are making too much of this. OS security is just one plank
in the process. A single or even collection of decnet connected nodes
not connected to other networks in any way, would still be perfectly
secure, vax, alpha or even X86, from the most common forms of
intrusion. Probably many vax and alpha systems running today and have
done for years under such conditions...

Chris

On 8/10/2022 7:32 AM, chris wrote:
> On 08/10/22 05:10, jimc...@gmail.com wrote:
>> It's unwise to assume that the best practices that DEC displayed in
>> the 1980s are still relevant in protecting customers running OpenVMS
>> in 2022.
>>
> I think we are making too much of this. OS security is just one plank
> in the process.

That is true. Standard software components, libraries, custom
application logic is where the most vulnerabilities are found.

> A single or even collection of decnet connected nodes
> not connected to other networks in any way, would still be perfectly
> secure, vax, alpha or even X86, from the most common forms of
> intrusion. Probably many vax and alpha systems running today and have
> done for years under such conditions...

Not perfectly secure.

Vulnerable to insider attack.

Arne

On 08/10/22 13:18, Arne Vajhøj wrote:
> On 8/10/2022 7:32 AM, chris wrote:
>> On 08/10/22 05:10, jimc...@gmail.com wrote:
>>> It's unwise to assume that the best practices that DEC displayed in
>>> the 1980s are still relevant in protecting customers running OpenVMS
>>> in 2022.
>>>
>> I think we are making too much of this. OS security is just one plank
>> in the process.
>
> That is true. Standard software components, libraries, custom
> application logic is where the most vulnerabilities are found.
>
>> A single or even collection of decnet connected nodes
>> not connected to other networks in any way, would still be perfectly
>> secure, vax, alpha or even X86, from the most common forms of
>> intrusion. Probably many vax and alpha systems running today and have
>> done for years under such conditions...
>
> Not perfectly secure.
>
> Vulnerable to insider attack.
>
> Arne
>

Agreed, but that applies to all systems. No secure system
should have access to external networks or internet
unless it's really needed. Justified on a case by case
basis and backed up by strong hardware based firewalling.

It's far easier to deny everything other than the essential,
rather than trying to deny the infinite variety of known
and unkown attack vectors, from a firewall pov anyway...

Chris

On 8/10/2022 10:34 AM, chris wrote:
> On 08/10/22 13:18, Arne Vajhøj wrote:
>> On 8/10/2022 7:32 AM, chris wrote:
>>> On 08/10/22 05:10, jimc...@gmail.com wrote:
>>>> It's unwise to assume that the best practices that DEC displayed in
>>>> the 1980s are still relevant in protecting customers running OpenVMS
>>>> in 2022.
>>>>
>>> I think we are making too much of this. OS security is just one plank
>>> in the process.
>>
>> That is true. Standard software components, libraries, custom
>> application logic is where the most vulnerabilities are found.
>>
>>> A single or even collection of decnet connected nodes
>>> not connected to other networks in any way, would still be perfectly
>>> secure, vax, alpha or even X86, from the most common forms of
>>> intrusion. Probably many vax and alpha systems running today and have
>>> done for years under such conditions...
>>
>> Not perfectly secure.
>>
>> Vulnerable to insider attack.
>
> Agreed, but that applies to all systems.

It is difficult to protect against all types of insider
attacks, but insider access to internal networks is easy
to protects against using secure network protocols.

> No secure system
> should have access to external networks or internet
> unless it's really needed. Justified on a case by case
> basis and backed up by strong hardware based firewalling.

Practically everyone has firewalls in place today.

> It's far easier to deny everything other than the essential,
> rather than trying to deny the infinite variety of known
> and unkown attack vectors, from a firewall pov anyway...

Yes.

Arne

On 2022-08-10, chris <chris-nospam@tridac.net> wrote:
> I think we are making too much of this. OS security is just one plank
> in the process. A single or even collection of decnet connected nodes
> not connected to other networks in any way, would still be perfectly
> secure, vax, alpha or even X86, from the most common forms of
> intrusion. Probably many vax and alpha systems running today and have
> done for years under such conditions...
>

Times change and so do security requirements.

At one time, it was considered acceptable to run TLS 1.0. No longer.

At one time, it was considered acceptable to use unencrypted protocols
such as telnet to connect to servers internally. No longer.

At one time, it was considered acceptable to run SMB1 servers and clients.
No longer.

Encryption algorithms once considered secure are removed as the
threat environment changes. Just look at SSH and VMS for an example
of this.

In many organisations, new directives and policies are issued on
a regular basis to tighten up internal security as the threats
faced by organisations evolve.

Saying that you don't need to apply those same rules to your VMS
systems because you believe they are somehow different would be
looked on very badly by many people.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-10, jimc...@gmail.com <jimcausey@gmail.com> wrote:
>> > ME are not really ISA specific.
>> >
>> > ME is AFAIK only available for x86-64 chipsets.
>> >
>> Unfortunately, AMD has its own version as well: :-(
>
> Most modern CPU implementations have management processors, co-processors, or supervisory processors running with high levels of privilege using embedded operating systems of their own. You see it on modern MIPS implementations, nearly every modern ARM SOC, POWER, as well as Intel and AMD. They're usually undocumented and ripe targets for security attacks or supply chain vulnerabilities.
>
> Moreover, side-channel attacks like Spectre and Meltdown were discovered on nearly every modern CPU implementation, and variants likely exist in every implementation of branch prediction and out-of-order execution over the past couple of decades; I would bet money that they exist on later generations of Alpha, for instance.

We are sleepwalking into a security nightmare.

At some point, there is going to be a major nation state or well-funded
hostile entity that decides to use these vulnerabilities and undocumented
features against us.

Modern CPUs, like modern browsers, have become way too complex for security
sensitive environments and unfortunately it's likely to take a major attack
for us to realise that.

At that point, we are probably screwed because of the severe damage
such an hardware-based attack would cause and the fact you can't just
turn off a switch to turn off the attack so an attacker could continue
to attack us until either the hardware was replaced or the firmware
eventually fixed (if the latter was possible).

In the meantime, they could have installed persistent access so they
can get back in at a later time.

Oh, and in case anyone thinks I am being melodramatic, I remind you
of this example of superb hardware-based engineering quality:

https://www.theregister.com/2017/05/05/intel_amt_remote_exploit/

For more recent examples, I refer you to the multiple UEFI vulnerabilities.

Try keeping your systems running securely with stuff like that hidden
in the hardware your operating systems run on.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 08/10/22 18:29, Simon Clubley wrote:
> On 2022-08-10, chris<chris-nospam@tridac.net> wrote:
>> I think we are making too much of this. OS security is just one plank
>> in the process. A single or even collection of decnet connected nodes
>> not connected to other networks in any way, would still be perfectly
>> secure, vax, alpha or even X86, from the most common forms of
>> intrusion. Probably many vax and alpha systems running today and have
>> done for years under such conditions...
>>
>
> Times change and so do security requirements.
>
> At one time, it was considered acceptable to run TLS 1.0. No longer.
>
> At one time, it was considered acceptable to use unencrypted protocols
> such as telnet to connect to servers internally. No longer.
>
> At one time, it was considered acceptable to run SMB1 servers and clients.
> No longer.
>
> Encryption algorithms once considered secure are removed as the
> threat environment changes. Just look at SSH and VMS for an example
> of this.
>
> In many organisations, new directives and policies are issued on
> a regular basis to tighten up internal security as the threats
> faced by organisations evolve.
>
> Saying that you don't need to apply those same rules to your VMS
> systems because you believe they are somehow different would be
> looked on very badly by many people.
>
> Simon.
>

The whole point I was making was that network isolated systems of
any sort will be immune from outside network related threats,
whatever the hardware or os type or revision. Of course, insider
threats can still be a problem, but that's handled at a different
levels and can be minimal in well organised and managed environment.

With many legacy systems, it's not possible to apply later security
protocols, so other methods must be used to make secure. The most
obvious being an isolated subnet. They may need to be kept running
for any number of reasons.

So much is a compromise in the real world...

Chris

On 8/10/2022 8:18 AM, Arne Vajhøj wrote:
> On 8/10/2022 7:32 AM, chris wrote:
>> On 08/10/22 05:10, jimc...@gmail.com wrote:
>>> It's unwise to assume that the best practices that DEC displayed in the 1980s
>>> are still relevant in protecting customers running OpenVMS in 2022.
>>>
>> I think we are making too much of this. OS security is just one plank
>> in the process.
>
> That is true. Standard software components, libraries, custom
> application logic is where the most vulnerabilities are found.
>
>> A single or even collection of decnet connected nodes
>> not connected to other networks in any way, would still be perfectly
>> secure, vax, alpha or even X86, from the most common forms of
>> intrusion. Probably many vax and alpha systems running today and have
>> done for years under such conditions...
>
> Not perfectly secure.
>
> Vulnerable to insider attack.
>
> Arne
>

If you got the SYSTEM password, or, physical access to the hardware, you're
always vulnerable ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 8/10/2022 5:35 PM, Dave Froble wrote:
> On 8/10/2022 8:18 AM, Arne Vajhøj wrote:
>> On 8/10/2022 7:32 AM, chris wrote:
>>> On 08/10/22 05:10, jimc...@gmail.com wrote:
>>>> It's unwise to assume that the best practices that DEC displayed in
>>>> the 1980s
>>>> are still relevant in protecting customers running OpenVMS in 2022.
>>>>
>>> I think we are making too much of this. OS security is just one plank
>>> in the process.
>>
>> That is true. Standard software components, libraries, custom
>> application logic is where the most vulnerabilities are found.
>>
>>>           A single or even collection of decnet connected nodes
>>> not connected to other networks in any way, would still be perfectly
>>> secure, vax, alpha or even X86, from the most common forms of
>>> intrusion. Probably many vax and alpha systems running today and have
>>> done for years under such conditions...
>>
>> Not perfectly secure.
>>
>> Vulnerable to insider attack.
>
> If you got the SYSTEM password,

True.

> or, physical access to the hardware,
> you're always vulnerable ...

On VMS yes. Other systems are better in this regard.

But the problem I was thinking above was network sniffing
of unencrypted network traffic (revealing maybe the
SYSTEM password).

Arne

On 8/10/2022 3:00 PM, chris wrote:
> On 08/10/22 18:29, Simon Clubley wrote:
>> Times change and so do security requirements.

>> In many organisations, new directives and policies are issued on
>> a regular basis to tighten up internal security as the threats
>> faced by organisations evolve.
>>
>> Saying that you don't need to apply those same rules to your VMS
>> systems because you believe they are somehow different would be
>> looked on very badly by many people.
>
> The whole point I was making was that network isolated systems of
> any sort will be immune from outside network related threats,
> whatever the hardware or os type or revision. Of course, insider
> threats can still be a problem, but that's handled at a different
> levels and can be minimal in well organised and managed environment.
>
> With many legacy systems, it's not possible to apply later security
> protocols, so other methods must be used to make secure. The most
> obvious being an isolated subnet. They may need to be kept running
> for any number of reasons.
>
> So much is a compromise in the real world...

It is very common with very fast rollout of security enhancements
in the frontline systems and much slower rollout at the backend
systems. Based on risk assessment and cost evaluation.

But unencrypted network protocols did not become obsolete 2 years
ago - more like 20 years ago.

So it is not slow rollout but no rollout. That can of course
also be done after risk assessment and cost evaluation, but I suspect
that in the majority of cases it is a no decision due to
lack of such process.

Arne

On 08/11/22 00:32, Arne Vajhøj wrote:
> On 8/10/2022 3:00 PM, chris wrote:
>> On 08/10/22 18:29, Simon Clubley wrote:
>>> Times change and so do security requirements.
>
>>> In many organisations, new directives and policies are issued on
>>> a regular basis to tighten up internal security as the threats
>>> faced by organisations evolve.
>>>
>>> Saying that you don't need to apply those same rules to your VMS
>>> systems because you believe they are somehow different would be
>>> looked on very badly by many people.
>>
>> The whole point I was making was that network isolated systems of
>> any sort will be immune from outside network related threats,
>> whatever the hardware or os type or revision. Of course, insider
>> threats can still be a problem, but that's handled at a different
>> levels and can be minimal in well organised and managed environment.
>>
>> With many legacy systems, it's not possible to apply later security
>> protocols, so other methods must be used to make secure. The most
>> obvious being an isolated subnet. They may need to be kept running
>> for any number of reasons.
>>
>> So much is a compromise in the real world...
>
> It is very common with very fast rollout of security enhancements
> in the frontline systems and much slower rollout at the backend
> systems. Based on risk assessment and cost evaluation.
>
> But unencrypted network protocols did not become obsolete 2 years
> ago - more like 20 years ago.
>
> So it is not slow rollout but no rollout. That can of course
> also be done after risk assessment and cost evaluation, but I suspect
> that in the majority of cases it is a no decision due to
> lack of such process.
>
> Arne

Suspect a lot of legacy system operators have no choice but to
stick with what they have, due some app or other, or industrial
control custom hardware. The cost involved to replace all that
might be beyond the company resources, as well as great risk in
terms of all aspects of the replacement system. Easy to understand
why they would stick with what they have for as long as possible.

Just need different strategies to make it as secure as possible...

Chris

On 10/08/2022 12:32, chris wrote:
> On 08/10/22 05:10, jimc...@gmail.com wrote:
>> On Saturday, August 6, 2022 at 1:02:11 AM UTC-7, David Wade wrote:
>>> The world has moved on. Simple example, encryption algorithms that were
>>> considered secure when VMS was evaluated are no longer considered
>>> secure. These days data must be encrypted when at rest.
>>>
>>> Read a few recent IBM announcements about the encryption algorithms they
>>> are adding to zOS the modern equivalent to MVS to get through current
>>> security requirments.
>>>
>>> Windows/NT also had similar security clearances, yet Digital (UK)
>>> produced a hardened version of Windows/NT that had enhanced network
>>> security (Secure/NT) and a hard disk encryption tool (Kilgetty) for the
>>> UK government, so even in the day it was recognised that security
>>> evaluations were incomplete.
>>>
>>> Saying VMS is secure is like saying its safe to use a 1950's car on
>>> todays roads.
>>
>> These points are critical.  No one is saying DEC didn't take security
>> seriously when they designed and built VAX/VMS; their assumptions were
>> based on the state of information security in the late 1970s and early
>> 1980s.  Many of those same engineers designed Windows NT's security
>> features, incorporating learning along the way.
>>
>> There are entire classes of security attacks that had not been
>> invented in 1977, or 1989, or in 2005, or even in 2020.  Protecting an
>> operating system requires dynamic, continuous investments and bug
>> fixes, participation in responsible reporting, and realism about the
>> capabilities of state actors and criminal enterprises.
>>
>> The slow pace of investment in OpenVMS likely helps its security
>> posture by reducing its attack surfaces.  How many old versions of VMS
>> are running in production, with out of date services or open source
>> components that are missing years of security patches?  How seriously
>> did the sustained engineering teams at HP take threat modelling,
>> penetration testing, and service hardening?  How many of VSI's limited
>> engineering resources go into modern security practices?  Hard to say.
>>
>> It's unwise to assume that the best practices that DEC displayed in
>> the 1980s are still relevant in protecting customers running OpenVMS
>> in 2022.
>>
>>
>>
>>
> I think we are making too much of this. OS security is just one plank
> in the process. A single or even collection of decnet connected nodes
> not connected to other networks in any way, would still be perfectly
> secure, vax, alpha or even X86, from the most common forms of
> intrusion. Probably many vax and alpha systems running today and have
> done for years under such conditions...

Of course that is true, but its becoming increasingly difficult to work
in such an environment, and the skills and tools to deliver it are
becoming harder to find.

>
> Chris
>

Dave

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/10/2022 5:35 PM, Dave Froble wrote:
>> On 8/10/2022 8:18 AM, Arne Vajhøj wrote:
>>> On 8/10/2022 7:32 AM, chris wrote:
>>>> On 08/10/22 05:10, jimc...@gmail.com wrote:
>>>>> It's unwise to assume that the best practices that DEC displayed in
>>>>> the 1980s
>>>>> are still relevant in protecting customers running OpenVMS in 2022.
>>>>>
>>>> I think we are making too much of this. OS security is just one plank
>>>> in the process.
>>>
>>> That is true. Standard software components, libraries, custom
>>> application logic is where the most vulnerabilities are found.
>>>
>>>>           A single or even collection of decnet connected nodes
>>>> not connected to other networks in any way, would still be perfectly
>>>> secure, vax, alpha or even X86, from the most common forms of
>>>> intrusion. Probably many vax and alpha systems running today and have
>>>> done for years under such conditions...
>>>
>>> Not perfectly secure.
>>>
>>> Vulnerable to insider attack.
>>
>> If you got the SYSTEM password,
>
> True.
>
>> or, physical access to the hardware,
>> you're always vulnerable ...
>
> On VMS yes. Other systems are better in this regard.
>
> But the problem I was thinking above was network sniffing
> of unencrypted network traffic (revealing maybe the
> SYSTEM password).

If one is sending these kind of credentials over the network in
clear text, then one _deserves_ to be 0wned.

And having said that, I've seen a place that used rsh with root in the
early 2000s .. *shudder* The only thing that saved them: this was on a
carefully airgapped network.

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison