On 6/3/2021 2:37 PM, Arne Vajhøj wrote:
> On 6/3/2021 1:04 PM, Bill Gunshannon wrote:
>> On 6/3/21 9:39 AM, Dave Froble wrote:
>>> On 6/3/2021 8:11 AM, Simon Clubley wrote:
>>>> VMS is missing security protections common in other operating systems.
>>>
>>> You mean all those "secure" systems that are constantly being hacked,
>>> invaded with ransomware and such.  Are those the "common security
>>> protections" you're talking about?
>>>
>>> Perhaps I'd rather be not as "secure" ...
>>
>> Either you don;lt understand any of this or you just haven't been paying
>> attention.  The places being hit are, in most of the stated cases, not
>> using any of the accepted security practices.
>
> The fact that it happened prove that they did something wrong.
>
> But they may have done 99 things right and only missed 1.
>
> That is the underlying problem in this: to protect a system you need to
> protect against all attacks - to successfully attack a system you
> only need to fine one that is not protected against.

It has now become public that the pipeline got hit because:
- a user had the same password at another site as for VPN to them
- that other site got compromised and the password database got stolen
and cracked
- MFA not used

Rather trivial, but a lot of breaches are considered trivial - after
the fact.

Arne

Den 2021-06-06 kl. 17:36, skrev Arne Vajhøj:
> On 6/6/2021 2:55 AM, Jan-Erik Söderholm wrote:
>> Den 2021-06-06 kl. 01:55, skrev Arne Vajhøj:
>>> On 6/5/2021 7:28 AM, Phillip Helbig (undress to reply) wrote:
>>>> In article <mn.2aa97e56e8d0753c.104627@invalid.skynet.be>, Marc Van Dyck
>>>> <marc.gr.vandyck@invalid.skynet.be> writes:
>>>>>> One of the ransom cases I've cleaned up after some years ago had the
>>>>>> perpetrator silently corrupt multiple backups over time, deeper than the
>>>>>> organization's backup rotation schedule. The perpetrator then
>>>>>> ransomed the
>>>>>> only remaining good copy of the organization's databases. In recent
>>>>>> ransom
>>>>>> attacks on other platforms, the attackers have been active in the target
>>>>>> organization's networks for weeks and months, too.
>>>>>>
>>>>> I suppose that people in this organization never tried restores ? Doing
>>>>> regular restores to ensure the integrity of your backups is one of the
>>>>> major recommendations, isn't it ?
>>>>
>>>> Yes, there is little point in doing a backup if you don't test the
>>>> restore.  But imagine, say, a database of several hundred terabytes.
>>>> Even if you can restore it, you can't necessarily tell if the data are
>>>> somehow corrupt.  Yes, checksums and so on will catch some things, but
>>>> not all.
>>>
>>> Traditional BACKUP only works good on a system with no activity.
>>> BACKUP/IGNORE=INTERLOCK does not solve the problem.
>>>
>>> To get a consistent backup of a large database, without significant
>>> downtime, then one need a snapshot capability where updates after
>>> time T does not change what is being backed up.
>>>
>>> I believe modern storage systems can do that easily. Even though
>>> I do not know much about the details - last time I was responsible
>>> for backups then DAT tapes was cool.
>>
>> You let the database tools handle the database backup and then use
>> your regular filesystem tools to backup the "database backup".
>>
>> $!
>> $ RMU/BACKUP/ONLINE/LOG/extend=65535   <DB-ROOT>  xxx.RBF
>> %RMU-I-QUIETPT, waiting for database quiet point at  6-JUN-2021 00:02:08.26
>> %RMU-I-RELQUIETPT, Database quiet point lock has been released at
>> 6-JUN-2021 00:02:08.28
>> %RMU-I-BCKTXT_00, Backed up root file xxx
>> %RMU-I-BCKTXT_02, Starting full backup of storage area (xxx)   at
>> 6-JUN-2021 00:02:08.30
>> %RMU-I-BCKTXT_12, Completed full backup of storage area (xxx)  at
>> 6-JUN-2021 00:05:04.72
>> %RMU-I-BCKTXT_02, Starting full backup of storage area (yyy)   at
>> 6-JUN-2021 00:05:04.72
>> %RMU-I-BCKTXT_12, Completed full backup of storage area (yyy)  at
>> 6-JUN-2021 00:06:53.49
>> %RMU-I-COMPLETED, BACKUP operation completed at  6-JUN-2021 00:06:53.53
>> $!
>>
>> Then approx an hour later ABC runs:
>>
>> Archive Backup Client for TSM on OpenVMS, Version V4.2.0.9
>> Copyright 1996-2010, Storage Solutions Specialists, Inc.
>> %ABC-I-SCNPASS, 01:43:47.19 Scanning file system for backup candidates
>> %ABC-S-BCKOK, saved xxx.RBF
>>
>> ABC is used very much as BACKUP with similar switches but
>> stores the backups on the central IBM TSM backup system.
>>
>> Now, this is not a "large" database, the RBF file is 17 M records.
>> On a "large" DB you need to do some other steps with incremental backups
>> or maybe selective backups, if not all your data is critical or not
>> updated. But RMU has the tools and options to do that.
>
> I believe that is a common model.
>
> But the rule is still that either the database will be unavailable
> for significant time or one need a snapshot capability where updates
> can be done but the backup sees the snapshot data at the time of the
> snapshot.
>
> Storage or file system or database - the basic problem is the same.
>
> Arne
>

Yes. Rdb solves that using a "quiet point". As can be seen from the log
file above, that took 2 sec (freezing and waiting for active transactions
to finish). EFter that 2 sec delay, all update activity are back to normal
while the backup continues to run. The data backed up is the data that
was there at the point in time of the "quiet point lock release".

And any "snapshot" data is only saved to the "snapshot file" in the case
that some process request to update it. If not, there is no reason to
copy any data, of course. 99% of the database will be untouched during
the backup and thus not copied to the snapshot file.

So most of the data backed up is "real" data, not snapshot data.

On 2021-06-05 20:21:51 +0000, Phillip Helbig (undress to reply said:

> In article <s9gb6o$ip7$1@dont-email.me>, Stephen Hoffman
> <seaohveh@hoffmanlabs.invalid> writes:
>
> By how much would ransom-ware attacks be reduced if there were no
> bitcoin and no anonymous internet?

Unclear.

The effects of Deny / Dissemble / Defer / Defend / Defund / Deter /
Destroy and of AML & KYC and other responses to crime and fraud and
particularly ransomware and to varying sorts of espionage are all open
to debate.

Too many organizations deny or defer or dissemble on topics of data
security and privacy and accept the risks and consequences around the
threats of ransomware and data breaches, while others can and do choose
to defend.

Defunding and deterring and destroying are national and international
discussions, and with international requirements or repercussions.

An anonymous internet is valuable to us all, for as long as we might
still have that. If we even still have that in an era of
increasingly-ubiquitous and pervasive surveillance.

Do ask some folks that are not in your relatively charmed social
position about why they either don't post, or why they post
anonymously. If they're willing to answer. Some of us are targets of
harassment, of abuse or of massive abuse, or of threats of violence up
to and legally-sanctioned death sentences.

Cryptocurrencies are speculative investments and regulatory-arbitrage
schemes at best, and self-organizing pyramid schemes and/or massive
frauds at worst, and that all usually doesn't end well for all but the
earliest investors. If it works out at all. Proofs-of-work and
proofs-of-space algorithms are just stupidly-consumptive designs in
general too, as those necessarily must be structured and provisioned to
always detect and defend against 51% "attacks".

--
Pure Personal Opinion | HoffmanLabs LLC

In article <s9j58f$m66$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes:

> > By how much would ransom-ware attacks be reduced if there were no
> > bitcoin and no anonymous internet?
>
> Unclear.

> An anonymous internet is valuable to us all, for as long as we might
> still have that. If we even still have that in an era of
> increasingly-ubiquitous and pervasive surveillance.
>
> Do ask some folks that are not in your relatively charmed social
> position about why they either don't post, or why they post
> anonymously. If they're willing to answer. Some of us are targets of
> harassment, of abuse or of massive abuse, or of threats of violence up
> to and legally-sanctioned death sentences.

I certainly understand that an anonymous internet is a boon for many
people. However, it does have a downside in that perfect anonymity and
uncrackable encryption do help criminals as well. One has to weigh up
the risks; neither choice is ideal.

> Cryptocurrencies are speculative investments and regulatory-arbitrage
> schemes at best, and self-organizing pyramid schemes and/or massive
> frauds at worst, and that all usually doesn't end well for all but the
> earliest investors. If it works out at all. Proofs-of-work and
> proofs-of-space algorithms are just stupidly-consumptive designs in
> general too, as those necessarily must be structured and provisioned to
> always detect and defend against 51% "attacks".

I am certainly not a fan of crypto currencies, for several reasons, and
am pleased that Elon Musk has now reduced the corresponding hype since
he realized (late, but still) that they are NOT GOOD for the
environment. However, it is clear that the ability to transfer money
anonymously has greatly aided the extortionists.

On 6/6/2021 12:45 PM, Jan-Erik Söderholm wrote:
> Den 2021-06-06 kl. 17:36, skrev Arne Vajhøj:
>> But the rule is still that either the database will be unavailable
>> for significant time or one need a snapshot capability where updates
>> can be done but the backup sees the snapshot data at the time of the
>> snapshot.
>>
>> Storage or file system or database - the basic problem is the same.
>
> Yes. Rdb solves that using a "quiet point". As can be seen from the log
> file above, that took 2 sec (freezing and waiting for active transactions
> to finish). EFter that 2 sec delay, all update activity are back to normal
> while the backup continues to run. The data backed up is the data that
> was there at the point in time of the "quiet point lock release".
>
> And any "snapshot" data is only saved to the "snapshot file" in the case
> that some process request to update it. If not, there is no reason to
> copy any data, of course. 99% of the database will be untouched during
> the backup and thus not copied to the snapshot file.
>
> So most of the data backed up is "real" data, not snapshot data.

Yes.

I think that is common as well.

I believe that SpiraLog would have worked similarly - if anyone
still remembers that.

Arne

On 6/4/2021 1:41 PM, Simon Clubley wrote:
> On 2021-06-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> An additional twist on ransomware these days is to copy some sensitive
> data before encrypting it and then threaten to release the sensitive
> data if you do not pay the ransom.
>
> That way, you may still have to pay even if you can recover your
> systems from backups.

Paying such blackmail is useless.

You have to assume that even if you do pay, your stolen data is going to
also be sold to someone that you do not want to see it.

I saw a report that one insurance company is no longer covering business
losses due to ransomware.

Regards,
-John

On 6/6/2021 9:15 PM, John E. Malmberg wrote:
> On 6/4/2021 1:41 PM, Simon Clubley wrote:
>> On 2021-06-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> An additional twist on ransomware these days is to copy some sensitive
>> data before encrypting it and then threaten to release the sensitive
>> data if you do not pay the ransom.
>>
>> That way, you may still have to pay even if you can recover your
>> systems from backups.
>
> Paying such blackmail is useless.
>
> You have to assume that even if you do pay, your stolen data is going to
> also be sold to someone that you do not want to see it.
>
> I saw a report that one insurance company is no longer covering business
> losses due to ransomware.
>
> Regards,
> -John

True fault lies with the first entity that paid any ransom. Without
that the bad guys would not realize what a gold mine they had.

Trusting thieves is the height of folly ...

Ok, a VMS question.

What, other than getting to run a program, could be done by the bad guys
on a VMS system? I confess, I have not studied the issue at all.

If the bad guys need to get access and run a program, would defenses
that check for valid programs running be successful?

So, yeah, if I can get access and run a process on VMS, much can be
done. And possible defenses could be set up. But if there are other
possibilities, one would need to know about them before considering
defenses.

--
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

In article <s9k0hc$lad$1@dont-email.me>, Dave Froble
<davef@tsoft-inc.com> writes:

> True fault lies with the first entity that paid any ransom. Without
> that the bad guys would not realize what a gold mine they had.

Indeed.

> What, other than getting to run a program, could be done by the bad guys
> on a VMS system? I confess, I have not studied the issue at all.

If that program is DELETE, then that's bad enough.

> If the bad guys need to get access and run a program, would defenses
> that check for valid programs running be successful?

DELETE is a valid program.

In many cases the ransom is not to get sensitive data (which, of course,
could be sold by the criminal), but rather just to get access to one's
own data so that normal operations could resume.

On 6/6/2021 10:33 PM, Dave Froble wrote:
> Ok, a VMS question.
>
> What, other than getting to run a program, could be done by the bad guys
> on a VMS system?  I confess, I have not studied the issue at all.
>
> If the bad guys need to get access and run a program, would defenses
> that check for valid programs running be successful?
>
> So, yeah, if I can get access and run a process on VMS, much can be
> done.  And possible defenses could be set up.  But if there are other
> possibilities, one would need to know about them before considering
> defenses.

That is a broad question, but some random answers.

There are different purposes of attacks including:
* make the system unusable (sabotage)
* steal sensitive information and sell it (espionage)
* encrypt all data and require a ransom to decrypt (ransomware)
* make small changes to data that will go undetected for a long time
(also sabotage)
* just put up a notice (ego hacking)

Obviously doing any of these require some sort of access.

It can be an interactive login (DECnet, telnet, ssh) or it can
be some network request (DECnet FAL, rsh/rexec, HTTP to unsafe
service, buffer overflow in some custom TCP application etc.).
Or maybe the vulnerability came with some software installed
or maybe some hardware.

It can come from LAN, private WAN or public internet.

It can go directly in to a privileged account or it can go
into an unprivileged account and use some other vulnerability
to get privs or it can go after an account that does not have
SYSPRV but does have full access to a certain application.

It can be a foreign intelligence service, foreign hackers, young
people from your local college or an insider (former or current
unhappy employee).

As soon as you turn the power on then ...

Arne

On 2021-06-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I believe modern storage systems can do that easily. Even though
> I do not know much about the details - last time I was responsible
> for backups then DAT tapes was cool.
>

DAT tapes were _never_ cool. :-)

DLT tapes, OTOH...

Simon.

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

On 2021-06-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I believe that SpiraLog would have worked similarly - if anyone
> still remembers that.
>

I remember that you apparently had to restore from backups if the
Spiralog volume ever got full. Oops...

Simon.

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

On 6/7/2021 8:11 AM, Simon Clubley wrote:
> On 2021-06-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I believe modern storage systems can do that easily. Even though
>> I do not know much about the details - last time I was responsible
>> for backups then DAT tapes was cool.
>
> DAT tapes were _never_ cool. :-)
>
> DLT tapes, OTOH...

DLT was very reliable but also expensive.

The original DAT (60 m) was not bad. I never had problems.
I think DAT went wrong when they started squeezing longer
tapes into the same size tape cartridge.

Arne

On 2021-06-06, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Ok, a VMS question.
>
> What, other than getting to run a program, could be done by the bad guys
> on a VMS system? I confess, I have not studied the issue at all.
>

If _that's_ what you are thinking in terms of, then you need to do some
serious reading.

A common attack vector is to inject code into a running program via
malformed inputs or malformed protocol packets.

Another attack vector is to use malformed protocol packets to get more
access than you should. That's how Heartbleed was able to read more
memory than should have been possible.

> If the bad guys need to get access and run a program, would defenses
> that check for valid programs running be successful?
>

You are thinking at the wrong level. They already have access if
they can get to a program running on a network port. They can then
probe that program to see if they can compromise it in some way.

> So, yeah, if I can get access and run a process on VMS, much can be
> done. And possible defenses could be set up. But if there are other
> possibilities, one would need to know about them before considering
> defenses.
>

You have already seen this twice on VMS, both from me and from the
DEFCON 16 researchers where we injected code we controlled into a
running interactive process. That's bad enough but think about how
devastating that could be if someone found a way to do that to a
network process.

You need to think a _lot_ wider than you appear to be currently thinking.

Simon.

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

On 2021-06-06 06:02:43 +0000, Phillip Helbig (undress to reply said:

> In article <s9h2t7$1qvs$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> <arne@vajhoej.dk> writes:
>
>>> Yes, there is little point in doing a backup if you don't test the
>>> restore. But imagine, say, a database of several hundred terabytes.
>>> Even if you can restore it, you can't necessarily tell if the data are
>>> somehow corrupt. Yes, checksums and so on will catch some things, but
>>> not all.

At the scale some of our apps are operating at now, silent Ethernet
checksum failures are to be expected.

>> Traditional BACKUP only works good on a system with no activity.
>> BACKUP/IGNORE=INTERLOCK does not solve the problem.
>>
>> To get a consistent backup of a large database, without significant
>> downtime, then one need a snapshot capability where updates after time
>> T does not change what is being backed up.
>
> Presumably with a database one would do a database backup, e.g.
> RMU/BACKUP, which gives a consistent result.

That's an older approach and as is the analogous RMS journaling, and
that does get a consistent backup—at the cost of blocking activity.

Basically, the quiesce function got moved from the app to the database,
and better tuned to app activity. But it's still present.

RMS journaling being a frequent winner of the most-forgotten LP award.

Newer app approaches tend not to use that design, for performance reasons.

Both BACKUP and RMU get into trouble with the amount of data involved,
and how long that task takes, and how much then gets blocked or
deferred.

The BACKUP design has ~reached its theoretical I/O performance limits,
and I'd expect the RMU design is close to those same limits.

For obvious reasons, SSD helps (massively) here. SSDs can mask a whole
lot of latent OS and app algorithm-performance messes.

On OpenVMS, an app quiesce and app cache flush and host-based volume
shadowset split is (vastly) faster than BACKUP or RMU /BACKUP.

Host-based volume shadowing being the all-time winner for LPs
overlooked while searching for distributed software RAID-1 features.

Which then leads to designs with live spare servers directly updated
(RAIS, etc), and to controller-level analogs to HBVS / RAID-1 splits.

Journaling right into a secondary server, which can write a
non-volatile backup for recovery and/or flush to SSD or HDD archives,
or can be live and running and current failover server.

And leads to in-memory designs (with archiving), as more than a few of
our databases fit into server memory—q.v. SAP HANA, etc—and as writing
to SSDs is, well, slow.

--
Pure Personal Opinion | HoffmanLabs LLC

On 6/7/2021 9:09 AM, Simon Clubley wrote:
> On 2021-06-06, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Ok, a VMS question.
>>
>> What, other than getting to run a program, could be done by the bad guys
>> on a VMS system? I confess, I have not studied the issue at all.
>>
>
> If _that's_ what you are thinking in terms of, then you need to do some
> serious reading.
>
> A common attack vector is to inject code into a running program via
> malformed inputs or malformed protocol packets.
>
> Another attack vector is to use malformed protocol packets to get more
> access than you should. That's how Heartbleed was able to read more
> memory than should have been possible.
>
>> If the bad guys need to get access and run a program, would defenses
>> that check for valid programs running be successful?
>>
>
> You are thinking at the wrong level. They already have access if
> they can get to a program running on a network port. They can then
> probe that program to see if they can compromise it in some way.
>
>> So, yeah, if I can get access and run a process on VMS, much can be
>> done. And possible defenses could be set up. But if there are other
>> possibilities, one would need to know about them before considering
>> defenses.
>>
>
> You have already seen this twice on VMS, both from me and from the
> DEFCON 16 researchers where we injected code we controlled into a
> running interactive process. That's bad enough but think about how
> devastating that could be if someone found a way to do that to a
> network process.
>
> You need to think a _lot_ wider than you appear to be currently thinking.
>
> Simon.
>

I'm not too sure just how much thinking I want to do. However, it seems
to me that access, while bad, cannot do much by itself. I'm thinking
that if someone with access cannot do anything, that might be a decent
defense.

It seems to me, and no, I don't know, that running various "standard"
software, such as a web server, offers the bad guys some possibilities,
none of which I'm aware of. So not using these standard products might
be some defense.

Opportunity seems to be a part of reported break-ins. Not much anyone
can do from inside to prevent that, disgruntled or dishonest employees,
same password used elsewhere, and such. I'm not thinking about such,
rather what might be possible to deflect internet based probes.

For what I'm looking at, I'm assuming that TCP/IP and sockets is the
path most or all probes might use. I'm not going to attempt to replace
TCP/IP, and it would be worthless anyway, since the entire purpose is to
talk to other computers. However, my custom usage of sockets could be a
fertile ground for looking for ways to prevent internet access. I['m
just not aware of how such could happen. But, where to start?

But, back to actually doing anything. If there was a database, the bad
guys could not get to, (and that itself is an issue), that had a list of
valid users and valid programs, with ways to verify the program was the
intended one, then image activation might be able to determine whether a
program, or process (have to think a bit more on processes) should be
activated.

--
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 2021-06-07 02:33:22 +0000, Dave Froble said:

> What, other than getting to run a program, could be done by the bad
> guys on a VMS system? I confess, I have not studied the issue at all.

Getting to run an app is pretty much game over.

> If the bad guys need to get access and run a program, would defenses
> that check for valid programs running be successful?

That's akin to what's called whitelisting, and it's one approach. It's
fairly common within Microsoft Windows configurations.

Latent flaws can still exist even in the approved apps, and the flaws
can be subtle.

> So, yeah, if I can get access and run a process on VMS, much can be
> done. And possible defenses could be set up. But if there are other
> possibilities, one would need to know about them before considering
> defenses.

There are a couple of discussions on this topic going on elsewhere.

I've been pondering creating a presentation on this topic as the
OpenVMS doc here is grossly inadequate.

Identify your core data, and work to get rid of all of that that you
can, and to protect what you must have and preserve.

Isolate apps with privileges into separate processes.

Avoid installed images with privileges, and avoid privileged shareable
images, and review the internal details of those that you must have.

Subsystem identifiers are your friend.

Isolate parsers to separate and minimally-privileged processes; allow
TMPMBX and/or NETMBX at most.

Implement telemetry in all production apps. Minimally, collect all app
errors, all app crashes, and crash details, as well as
use-of-privileges and manually-triggered app-critical functions and
administrative functions.

Don't try to recover from unrecognized or unexpected errors. Log, exit,
and restart.

Off-host logging; whether syslogd or otherwise. Logs are useful after a
breach, but otherwise too much data to sift.

Automate scans of your configurations, including digital signatures.

PCSI kits for local app installs for faster recovery post-breach.

Find and rate-limit your sensitive APIs within your apps, as some of
your own APIs can potentially be used to brute-force your own
environment—akin to password brute-forcing.

Look for and constrain the directories and files and APIs that your
user interface and your network interface apps can write to, and can
read from.

CAPTIVE is just a start for hardening DCL procedures.

Encrypt your critical data while at rest (and OpenVMS is not good at
this), and encrypt all of your network connections.

Backups and telemetry data and crash data cannot be writeable once
written, and access credentials needed for writing and for reading kept
separate.

All app-critical production functions must be scripted, outside of
exceptional circumstances.

Collect baseline app and user and network activity data, and detect
deviations from same. There are techniques for detecting these
deviations, too.

Etc.

--
Pure Personal Opinion | HoffmanLabs LLC

Den 2021-06-07 kl. 15:59, skrev Stephen Hoffman:
> On 2021-06-06 06:02:43 +0000, Phillip Helbig (undress to reply said:
>
>> In article <s9h2t7$1qvs$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>> <arne@vajhoej.dk> writes:
>>
>>>> Yes, there is little point in doing a backup if you don't test the
>>>> restore.  But imagine, say, a database of several hundred terabytes.
>>>> Even if you can restore it, you can't necessarily tell if the data are
>>>> somehow corrupt.  Yes, checksums and so on will catch some things, but
>>>> not all.
>
> At the scale some of our apps are operating at now, silent Ethernet
> checksum failures are to be expected.
>
>>> Traditional BACKUP only works good on a system with no activity.
>>> BACKUP/IGNORE=INTERLOCK does not solve the problem.
>>>
>>> To get a consistent backup of a large database, without significant
>>> downtime, then one need a snapshot capability where updates after time T
>>> does not change what is being backed up.
>>
>> Presumably with a database one would do a database backup, e.g.
>> RMU/BACKUP, which gives a consistent result.
>
> That's an older approach and as is the analogous RMS journaling, and that
> does get a consistent backup—at the cost of blocking activity.

What "cost of blocking activity"?

>
> Basically, the quiesce function got moved from the app to the database, and
> better tuned to app activity. But it's still present.

Right, but it is just a short activity (waiting for any running r/w
transaction to end, so it very much depends on the usage profile).
After that, there is no blocking (from the RMU backup activity).

> Both BACKUP and RMU get into trouble with the amount of data involved, and
> how long that task takes, and how much then gets blocked or deferred.

BACKUP doesn't have any on-line mode like RMU, so it is hard to compare.
Why should anything get "blocked or deferred"?

> The BACKUP design has ~reached its theoretical I/O performance limits, and
> I'd expect the RMU design is close to those same limits.

Maybe, but the limits are far higher for RMU. You can run a multi process
RMU backup operation where differnt processes takes care of differnt parts
of the database in parallel. The limit is how much hardware you give RMU
to work with.

> On OpenVMS, an app quiesce and app cache flush and host-based volume
> shadowset split is (vastly) faster than BACKUP or RMU /BACKUP.

Yes, the HBVS split is fast, but you still need to backup your plit
shadow set, don't you?

On 6/7/2021 10:20 AM, Dave Froble wrote:
> I'm not too sure just how much thinking I want to do.  However, it seems
> to me that access, while bad, cannot do much by itself.  I'm thinking
> that if someone with access cannot do anything, that might be a decent
> defense.
>
> It seems to me, and no, I don't know, that running various "standard"
> software, such as a web server, offers the bad guys some possibilities,
> none of which I'm aware of.  So not using these standard products might
> be some defense.

Not running a web server will be more secure than running a web server.

But if you have to run a web server for valid business reasons, then
you are likely better off with a standard web server running standard
stuff.

There are frequently found vulnerabilities in such standard stuff, but
chances are that there will be more vulnerabilities in the home made
CGI script written in Fortran.

> Opportunity seems to be a part of reported break-ins.  Not much anyone
> can do from inside to prevent that, disgruntled or dishonest employees,
> same password used elsewhere, and such.  I'm not thinking about such,
> rather what might be possible to deflect internet based probes.

You should design for multi layer defense in depth.

Do not think "I create this unbreakable barrier and then I am good".

Think "I create this strong barrier and if by some means the bad guys
come through then I have this other strong barrier and after that I have
another and ...".

Detection is important. It is bad to get hacked, but it is really bad to
get hacked and not know it.

> For what I'm looking at, I'm assuming that TCP/IP and sockets is the
> path most or all probes might use.  I'm not going to attempt to replace
> TCP/IP, and it would be worthless anyway, since the entire purpose is to
> talk to other computers.  However, my custom usage of sockets could be a
> fertile ground for looking for ways to prevent internet access.  I['m
> just not aware of how such could happen.  But, where to start?

TCP/IP is used by almost all network traffic today. Most computers
only have TCP/IP networking. No surprise that attacks comes in that
way.

If you write the socket code then it is up to you to write it safely.

> But, back to actually doing anything.  If there was a database, the bad
> guys could not get to, (and that itself is an issue), that had a list of
> valid users and valid programs, with ways to verify the program was the
> intended one, then image activation might be able to determine whether a
> program, or process (have to think a bit more on processes) should be
> activated.

Most database authenticate requests.

A firewall that only allows nodes that need to connect to the
database to do so can help.

Maybe it is possible to set it up so that connecting applications
need to have a client certificate that the database server knows
to connect.

There are technical possibilities.

Arne

On 6/6/21 11:42 AM, Arne Vajhøj wrote:
> On 6/3/2021 2:37 PM, Arne Vajhøj wrote:
>> On 6/3/2021 1:04 PM, Bill Gunshannon wrote:
>>> On 6/3/21 9:39 AM, Dave Froble wrote:
>>>> On 6/3/2021 8:11 AM, Simon Clubley wrote:
>>>>> VMS is missing security protections common in other operating systems.
>>>>
>>>> You mean all those "secure" systems that are constantly being
>>>> hacked, invaded with ransomware and such.  Are those the "common
>>>> security protections" you're talking about?
>>>>
>>>> Perhaps I'd rather be not as "secure" ...
>>>
>>> Either you don;lt understand any of this or you just haven't been paying
>>> attention.  The places being hit are, in most of the stated cases, not
>>> using any of the accepted security practices.
>>
>> The fact that it happened prove that they did something wrong.
>>
>> But they may have done 99 things right and only missed 1.
>>
>> That is the underlying problem in this: to protect a system you need to
>> protect against all attacks - to successfully attack a system you
>> only need to fine one that is not protected against.
>
> It has now become public that the pipeline got hit because:
> - a user had the same password at another site as for VPN to them
> - that other site got compromised and the password database got stolen
>   and cracked
> - MFA not used
>
> Rather trivial, but a lot of breaches are considered trivial - after
> the fact.
>

As I have said before, the only breach we had when I was the
administrator of the CS Department was one user account and
that was because he used his department password for a WordPress
account on the Web somewhere and we all know how good their
security is.

Humans are the biggest threat to IT Systems and, so far, no one
has figured out how to patch them fix the problem.

bill

On 6/7/2021 1:45 PM, Bill Gunshannon wrote:
> On 6/6/21 11:42 AM, Arne Vajhøj wrote:
>> On 6/3/2021 2:37 PM, Arne Vajhøj wrote:
>>> On 6/3/2021 1:04 PM, Bill Gunshannon wrote:
>>>> On 6/3/21 9:39 AM, Dave Froble wrote:
>>>>> On 6/3/2021 8:11 AM, Simon Clubley wrote:
>>>>>> VMS is missing security protections common in other operating
>>>>>> systems.
>>>>>
>>>>> You mean all those "secure" systems that are constantly being
>>>>> hacked, invaded with ransomware and such. Are those the "common
>>>>> security protections" you're talking about?
>>>>>
>>>>> Perhaps I'd rather be not as "secure" ...
>>>>
>>>> Either you don;lt understand any of this or you just haven't been
>>>> paying
>>>> attention. The places being hit are, in most of the stated cases, not
>>>> using any of the accepted security practices.
>>>
>>> The fact that it happened prove that they did something wrong.
>>>
>>> But they may have done 99 things right and only missed 1.
>>>
>>> That is the underlying problem in this: to protect a system you need to
>>> protect against all attacks - to successfully attack a system you
>>> only need to fine one that is not protected against.
>>
>> It has now become public that the pipeline got hit because:
>> - a user had the same password at another site as for VPN to them
>> - that other site got compromised and the password database got stolen
>> and cracked
>> - MFA not used
>>
>> Rather trivial, but a lot of breaches are considered trivial - after
>> the fact.
>>
>
> As I have said before, the only breach we had when I was the
> administrator of the CS Department was one user account and
> that was because he used his department password for a WordPress
> account on the Web somewhere and we all know how good their
> security is.
>
> Humans are the biggest threat to IT Systems and, so far, no one
> has figured out how to patch them fix the problem.
>
> bill
>
>

First, do away with passwords. Don't some phones now need a fingerprint
to access? Guess that data could be copied, and used. Remote access is
always an issue, and it just ain't going away.

Then, one must convince the management to cough up the funds for such
things. That ain't gonna happen. At least not before lots of pain.

--
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 6/7/21 2:11 PM, Dave Froble wrote:
> On 6/7/2021 1:45 PM, Bill Gunshannon wrote:
>> On 6/6/21 11:42 AM, Arne Vajhøj wrote:
>>> On 6/3/2021 2:37 PM, Arne Vajhøj wrote:
>>>> On 6/3/2021 1:04 PM, Bill Gunshannon wrote:
>>>>> On 6/3/21 9:39 AM, Dave Froble wrote:
>>>>>> On 6/3/2021 8:11 AM, Simon Clubley wrote:
>>>>>>> VMS is missing security protections common in other operating
>>>>>>> systems.
>>>>>>
>>>>>> You mean all those "secure" systems that are constantly being
>>>>>> hacked, invaded with ransomware and such.  Are those the "common
>>>>>> security protections" you're talking about?
>>>>>>
>>>>>> Perhaps I'd rather be not as "secure" ...
>>>>>
>>>>> Either you don;lt understand any of this or you just haven't been
>>>>> paying
>>>>> attention.  The places being hit are, in most of the stated cases, not
>>>>> using any of the accepted security practices.
>>>>
>>>> The fact that it happened prove that they did something wrong.
>>>>
>>>> But they may have done 99 things right and only missed 1.
>>>>
>>>> That is the underlying problem in this: to protect a system you need to
>>>> protect against all attacks - to successfully attack a system you
>>>> only need to fine one that is not protected against.
>>>
>>> It has now become public that the pipeline got hit because:
>>> - a user had the same password at another site as for VPN to them
>>> - that other site got compromised and the password database got stolen
>>>    and cracked
>>> - MFA not used
>>>
>>> Rather trivial, but a lot of breaches are considered trivial - after
>>> the fact.
>>>
>>
>> As I have said before, the only breach we had when I was the
>> administrator of the CS Department was one user account and
>> that was because he used his department password for a WordPress
>> account on the Web somewhere and we all know how good their
>> security is.
>>
>> Humans are the biggest threat to IT Systems and, so far, no one
>> has figured out how to patch them fix the problem.
>>
>> bill
>>
>>
>
> First, do away with passwords.  Don't some phones now need a fingerprint
> to access?  Guess that data could be copied, and used.

A couple of high school kids beat fingerprint scanners several years
ago. I'm sure the pros beat it long before that.

> Remote access is
> always an issue, and it just ain't going away.
>
> Then, one must convince the management to cough up the funds for such
> things.  That ain't gonna happen.  At least not before lots of pain.
>

And then you have facial recognition. I understand that has already
been beaten with a photograph. (And we don't even need to go into the
serious potential problems with false negatives!!)

bill

On 6/7/2021 2:11 PM, Dave Froble wrote:
> On 6/7/2021 1:45 PM, Bill Gunshannon wrote:
>> On 6/6/21 11:42 AM, Arne Vajhøj wrote:
>>> It has now become public that the pipeline got hit because:
>>> - a user had the same password at another site as for VPN to them
>>> - that other site got compromised and the password database got stolen
>>>    and cracked
>>> - MFA not used
>>>
>>> Rather trivial, but a lot of breaches are considered trivial - after
>>> the fact.
>>
>> As I have said before, the only breach we had when I was the
>> administrator of the CS Department was one user account and
>> that was because he used his department password for a WordPress
>> account on the Web somewhere and we all know how good their
>> security is.
>>
>> Humans are the biggest threat to IT Systems and, so far, no one
>> has figured out how to patch them fix the problem.
>
> First, do away with passwords.  Don't some phones now need a fingerprint
> to access?  Guess that data could be copied, and used.  Remote access is
> always an issue, and it just ain't going away.

Finger print check and password check is not the same type of check.

If you sit at your PC and login at a server 1000 miles away, then
finger print may make sense for the PC to verify that you are
who you are because the PC trust itself, but finger print is
just a long and fuzzy password for the server because
it does not trust the PC.

I believe current fashion in server side authentication is
login with username + password + some MFA like using your phone
(text message with code, app notification with code, app approval
etc.).

Arne

On 6/7/2021 1:45 PM, Bill Gunshannon wrote:
> On 6/6/21 11:42 AM, Arne Vajhøj wrote:
>> It has now become public that the pipeline got hit because:
>> - a user had the same password at another site as for VPN to them
>> - that other site got compromised and the password database got stolen
>>    and cracked
>> - MFA not used
>>
>> Rather trivial, but a lot of breaches are considered trivial - after
>> the fact.
>>
>
> As I have said before, the only breach we had when I was the
> administrator of the CS Department was one user account and
> that was because he used his department password for a WordPress
> account on the Web somewhere and we all know how good their
> security is.

8 printable character hash approx. equals 48 bit hash and
256 or 8192 rounds of MD5 hash.

Not good per 2021 standards. But worse has been seen in the wild.

Arne

On 2021-06-07 18:11:32 +0000, Dave Froble said:

> First, do away with passwords. Don't some phones now need a
> fingerprint to access?

Various Apple iPad, iPhone, and Mac models use biometrics (Face ID, or
Touch ID) as a means to reduce the frequency of prompting for the
passcode or password.

But not to replace the password.

All of those models do require a passcode or password for access, and
use the passcode or password for access to the key used for data
encryption and decryption; what Apple calls accessing a "keybag".

As for alternatives to passwords, we're getting closer with RFID
proximity tags and other tools. But we're not there yet.

Digital certificates are also effectively gonzo-length passwords with
some extra added math, and certificates aren't going away any time soon.

> Guess that data could be copied, and used.

That storage is part of what the so-called secure enclave is used for
with Apple devices; to make access to biometric data more difficult.

There've been discussions around here about password and certificate
protections and storage for OpenVMS, and about support for SGX and TPM
enclaves for secure computing and secure storage, but that's not (yet?)
on the VSI roadmap.

Biometrics can have pitfalls, too. Face ID can mis-detect close family
members, just to keep things interesting.

> Remote access is always an issue, and it just ain't going away.

Multi-factor authentication somewhat reduces the risk of getting
phished, among other approaches. There are various apps that permit
phones and watches to provide a second factor for a login, too.

> Then, one must convince the management to cough up the funds for such
> things. That ain't gonna happen. At least not before lots of pain.

Incremental changes are hopefully typical, for apps that are actively
maintained.

But yes, there are a lot of insecure apps around on OpenVMS, and
insecure OpenVMS configurations.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-06-06 18:47:43 +0000, Stephen Hoffman said:

> On 2021-06-05 20:21:51 +0000, Phillip Helbig (undress to reply said:
>
>> In article <s9gb6o$ip7$1@dont-email.me>, Stephen Hoffman
>> <seaohveh@hoffmanlabs.invalid> writes:
>>
>> By how much would ransom-ware attacks be reduced if there were no
>> bitcoin and no anonymous internet?
>
> Unclear.

In other news, press reports that US DOJ and FBI claim to have acquired
the wallet private key and having seized the server that was allegedly
holding the Colonial Pipeline ransom payment.

--
Pure Personal Opinion | HoffmanLabs LLC