[Info-vax] OpenVMS x64 Atom project

[Stephen Hoffman]

On 2021-06-05 09:21:30 +0000, Marc Van Dyck said:

> Stephen Hoffman presented the following explanation :
>> 
>> 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 ?

How many folks here full-path test their restores at all?  [hint: less 
than all.]

Then how many of that group test those restores more often than their 
backup rotation depth?

Then how many of that smaller group verify the database structures?

Then how many of that yet smaller group verify the contents of the 
database or the configuration files or other changes against production?

[Compared with some other platforms, OpenVMS is... bad... at 
re-installing without requiring manual effort, too. See previous 
newsgroup discussions of (the lack of) provisioning, and of migrating 
to PCSI kits for ~everything local, among other messes.  How many here 
install your whole environment repeatedly, and from a kit? Automated 
app deployments, with automated app migrations? But I digress.]

Would I have done the backups differently than the sequence they'd been 
using, given the software and hardware constraints? Probably not. Which 
yes, means I would have gotten caught out, too.

Even if keeping deeper backups, is restoring that old data from prior 
to a longer-duration corruption even going to be appropriate and 
useful? For many of the apps I've worked with, it'll be a disaster. 
Ordering and fulfillment data gets stale fast, for instance.

Flip this around all and ask yourself—knowing what each of you knows 
about your own backup or failover implementations—how would you 
deliberately corrupt your own backups and your own production data 
preservation strategies such that even performing the data recovery 
would be more expensive than paying off the ransom, then start looking 
at what to do to detect or to avoid that. What can be done deliberately 
to cause problems, too. Not what happens when a tape library becomes 
unreadable or unavailable, or a backup server drops offline with the 
primary, or whatever is appropriate for your particular data 
preservation implementation. And related to this, at what can be done 
to detect intruders within your network earlier. Then see if you can 
fit these changes into what for many is an ever-shrinking budget, just 
for added entertainment.



-- 
Pure Personal Opinion | HoffmanLabs LLC