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 <[email protected]> To: [email protected] 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 <[email protected]> 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 > [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
