Makes me wonder.. some network products have a 'total lockdown' mode that stops *anything* network. Like pulling the plug.
IBM can have a similar thing for z/OS TCPIP/SNA networks but I reckon it's more effective if a similar lockdown (ugh) feature exists for RACF instead. Of course, this will mean a whole lot of things will now start failing (perhaps this feature can also write such lockdown-initiated violations into a special report), but it may be worth shuttering things down before things can get worse. Alternatively, storage boxes need to get intelligent with their metadata. - KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, September 7, 2020 5:04 PM, R.S. <[email protected]> wrote: > My €0,02 > Ransomware on z/OS is very unlikely, but it is possible. We cannot say > it is impossible. > The possibility depends on some circumstances which affect the results > and possible prevention. It will be disscuessed. below (a little bit). > > Will backup help? NO! > Backup may be last resort, especially for operating system itself and > batch data. Not for online processing. In this case that could mean > outage and data loss. Imagine lost of half day transactions in a bank... > It is disaster for many businesses. > What about backup from tape and forward recovery from transaction log? > Hey, do you have log? Why can we assume the log is safe when we consider > tables are "ransomwared"? (encrypted by hacker - let me use this neologism) > And what about tape data? There were many voices about virtual tapes - > saying it's not the same as physical tape. Oh, yes - physical cart is > sexy. You can see it, you can touch it and you can remove it from ATL > and keep on you desk. Or even send it to the vault. > First: who removes tape from ATL? And why? Nowadays it can be poor > replacement for second ATL in remote location. Or third copy. Always > backlevel a little. > And how can you know the data on tape is OK and it is not ransomwared > copy of ransomwared dataset? Can I smell it? NO. > Hello - is it possible hacker ransomwared backups on the tape? Why not? > We just assumed he is able to ransomware DASD data. > Such cases did take a place in Windows world. > > Conclusion: the only effective way is to do not allow ransomware attack > to happen. Yes, we have to prevent it. All other ideas are like good > advices to a guy after his house was already robbed. Too late. You > already lost a lot. > > Reminder: all methods like backup, remote copy, third datacenter, tapes > in vault, etc. will NOT help for ANY PROBLEM. They will help for some > problems only. We are never 100% safe. It can be 99,9% or 99,9999%, but > the gap exists. What's in the gap? Example: Terrorist attack can destroy > our datacenter. There is no reason to assume the terrorists want to > attack us, but we cannot say it is impossible. But it is also possible > the terrorists would attack all our datacenters. BTW: such attack is not > only matter of wall thickness, sometimes it can be false pizza courier > with gun and hostages. > > And regarding IPL in VTS environment: AFAIK it is quite possible to IPL > from virtual tape volume. IMHO tape IPL as problem recovery seems to be > obsolete, maybe except poor installations. It is much more convenient to > have rescue LPAR with small z/OS image. It is much faster and more > convenient. Bigger shops may have rescue system cloned to any DASD box > in the installation, it can be IPLable from any CPC, including DR site, > etc. > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Radoslaw Skorupka > Lodz, Poland > > W dniu 04.09.2020 o 20:50, Jesse 1 Robinson pisze: > > > 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 > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza > prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: [email protected]. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, > NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who disseminates > (copies, distributes) this message or takes any similar action, violates the > law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00-950 Warszawa,www.mBank.pl, e-mail: [email protected]. District Court for > the Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 0000025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > > 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
