1. There seem to be a lot of sites that don't follow BCP for backup
2. A robust policy will assume threats from insiders.
3. Ransomware is not the only reason that duplexed backups with
at least one copy kept remotely are prudent. Assume that there
will be natural, e.g., tornado, and man made disasters, and plan
accordingly.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Tony Thigpen <[email protected]>
Sent: Friday, September 4, 2020 3:54 PM
To: [email protected]
Subject: Re: Ransoming a mainframe disk farm
I was recently asked about this by management. I may have missed
something, but below is my response, which I expect some will poke holes in.
First, all my dasd and VTL tapes are maintained in z-only devices. They
are not used, or accessed by PC based devices. We don't run z-Linux
either. My disks are not even on the network. My VTL is on the network,
but not as a shared drive to any pc. It just uses the network to remote
sync.
You site may have shared dasd or other things I don't, so the items
below may applicable to you.
--- start of my reply to management ----
Let's see how I would do it.
1) I have to get a virus with keystroke logging into a PC where someone
with RACF clearance is setting.
2) I would have to know he has access to a z/OS and I would have to
figure out the IP address of his z/OS.
3) I would have to figure out how to FTP a job into JES2 on z/OS, in a
class that will actually run, using his security credentials for z/OS,
not the security credentials on is PC.
4) I would have to submit a job to run on the z/OS that:
a) Creates a PDS
b) Catalogs a program into that PDS
c) Runs that program from the PDS
(I can't depend on access to known PDSs and I don't know any of the
site specific PDS names.)
5) That program would have to:
a) Figure out what tape manager is used.
b) Individually mount each tape and write over it somehow bypassing
the tape manger's "write prevention" protection. And, somehow do this
without anybody noticing since it may take days to encrypt everything
c) When done encrypting tapes, then spin though all attached dasd and
overwrite every file with an encrypted file, again, bypassing all "write
prevention" protection. And, I would have to make sure that I did not
encrypt the system packs until I have finished with the data packs or
the system would crash before the data was encrypted.
I don't think you can get the first few steps done, and even if you did,
it's just not going to happen to completion without someone noticing and
stopping it.
Also, ransomware really depends on somebody not having good backups. The
use of offsite backups, which most any zOS installation have, really
does not yield an environment where ransomware can easily cripple a site.
--- end of my reply to management ----
Tony Thigpen
Jesse 1 Robinson wrote on 9/4/20 2:50 PM:
> It’s Friday, so don’t rag on me for venturing into IT fiction. No one has hit
> us with this challenge (yet), but it could happen.
>
> Ransomware is much in the news these days. As unlikely as it might be, some
> nefarious genius manages to lock you out of your entire disk farm and demands
> rubies and bitcoin to remove the lock. Meanwhile your shop is out of the
> water. You have everything meticulously mirrored to another site, but as with
> any good mirror, the lock has been reflected in your recovery site.
>
> The classic mainframe response--short of forking over the ransom--would be to
> IPL a standalone DSS restore tape, then locate and mount standard offload
> backup tapes. Restore enough key volumes to IPL a minimal system, then
> proceed to restore (all) other volumes. It will take a while, but it will
> work. Eventually.
>
> Now consider a smartly modern shop that has taken the advice of a generation
> of hired gurus and eliminated 'real tape' altogether. No more physical tapes.
> No more physical tape drives.
>
> What would be your sage advice?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> [email protected]
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
