And to take this one step further (really one step too far), IBM boxes
(DS and TS) have a built-in function called Secure Data Overwrite, so
that before an old, replaced box goes out the door, the user can get a
certification that all their old data is truly overwritten with multiple
passes. Some customers require this even if the box going out is
encrypted with an external key, just to be sure. The certification
report shows the overwrites are at the internal disk level (not the
logical tape level) so that should include anything that was once a
Virtual WORM volume, directories, etc.
On a TS box this process seems to take days, so IBM does it remotely.
Now, it could be they even *initiate* the process remotely. If so, that
would mean there's a slight possibility that a hacker who gains access
to the machine via the IBM path could overwrite every byte on a tape
box, making the encrypted ransomware disks far more valuable.
Disclaimer: This is the first I've heard of a Virtual WORM volume, and
despite what I said above, that sounds like an excellent solution to the
problem.
On 9/5/2020 8:38 AM, Russell Witt wrote:
John,
But what happens if the virtual tape environment itself was over-written? That is where
the concept of "virtual WORM" devices can help. A virtual WORM volume cannot be
over-written. And if your tape management system itself is protected, the tapes will not
be scratched until they should be (cycle control or GDG limit or xxx days). While the
concept of a virtual WORM seems bizarre (its virtual, not physical) - the ability to
protect against over-writing is a huge safe-guard if you are seriously worried about some
type of insider threat. After all, the first thing a good insider hack would target is
the audit trail of their own activities and most commonly that audit trail will be backed
up on tape.
Russell Wittopinions are all my own (and I have a lot of them)
-----Original Message-----
From: John McKown <john.archie.mck...@gmail.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, Sep 5, 2020 6:47 am
Subject: Re: Ransoming a mainframe disk farm
If I were to consider this (which I don't because my shop _is_ going away
1Q2021), what I would do is have a "golden image" (aka sysprog sandbox or
the GI) in a different LPAR. This image would have access to all attached
devices, including sharing a virtual tape environment. But the "core"
volumes would be _isolated_ from all other LPARs via the IODF / HCD. This
would include the GI specific catalogs (at least the master) and RACF (or
TSS or ACF2) database. The GI would do at least weekly backups of all the
volumes to the virtual tape. So the GI could be used to recover the other
systems' volumes.
If there is no virtual tape environment, then there needs to be a separate,
GI only, set of DASD which would be used for the backups of the real
volumes. Of course, this doubles the size of your DASD farm. For the truly
paranoid, and rich, this DASD would be on an entirely separate array which
is not accessible from any LPAR other than the GI LPAR.
Or, as I have actually done, use DFDSS (or FDR or ???) to make volume level
backups & download them to a USB drive. USB drives can be mind boggling
huge today. I saw a flash drive with 1TiB. But an USB attached SSD can be
even bigger. LIke this 16TiB USB 3.0 attached, encrypted, array: (there is
also a 30 TiB array -- of course you'll need a lot if you're talking about
a PetaByte environment).
https://smile.amazon.com/Buslink-CipherShield-CSE16TSSDB4SU3-Hardware-Encrypted/dp/B01JVVHYZM/ref=sr_1_2?dchild=1&keywords=usb+ssd&pd_rd_r=5a1bbdc9-acaa-48d2-9518-4bcd087cd0d8&pd_rd_w=OrRWX&pd_rd_wg=6dxyr&pf_rd_p=e47220c0-687b-448f-b180-4a20654b7464&pf_rd_r=8BZ5ET5XHGMBMD3A23E7&qid=1599306202&refinements=p_n_feature_three_browse-bin%3A6797522011&s=pc&sr=1-2
On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson <jesse1.robin...@sce.com>
wrote:
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
robin...@sce.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
