Re: Ransoming a mainframe disk farm
kekronbekron wrote: >Thank you Tim, would you be able to share any info about #2 >here.. ? Yes, let's start with this important announcement: https://www.ibm.com/downloads/cas/US-ENUS220-037-CA/name/US-ENUS220-037-CA.PDF - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Thank you Tim, would you be able to share any info about #2 here.. ? - KB ‐‐‐ Original Message ‐‐‐ On Tuesday, September 8, 2020 10:27 AM, Timothy Sipples wrote: > Kekronbekron wrote: > > > Thinking about it ... it would be far simpler (than anti-ransomware > > capability in storage, or lock-all behaviour) if there were a RACF > > HealthChecker that looks for abnormal enc/dec activity. What 'normal' > > is can be learnt from a year's worth of actual enc/dec-related SMF > > data. > > There are tools with capabilities like the ones you're describing. > > I have a couple comments: > > 1. There are some excellent ransomware (and similar non-ransomware > disaster scenario) defenses available based on "out of band" controls and > lockouts. IBM DS8000 SafeGuarded Copy is one such example, a really > important one that's the foundation for some other valuable resiliency > capabilities. However, I have worked with some organizations that still > (also) want to maintain total physical and electronic (wired, wireless) > separation for certain data. You can achieve total separation in a few > ways, such as physical tape cartridges (usually WORM, preferably > encrypted) ejected from tape libraries and vaulted "afar." Of course the > costs include elongated Recovery Point Objectives (RPOs) and Recovery Time > Objectives (RTOs), but in some cases the costs are tolerable or at least > tolerated. > > You cannot really keep data completely, absolutely separate if you care > about retrieving it. You can only maintain separation with at least one > adjective added, such as "physically and electronically separate storage > media," which is not the same as "storage media separated from all > possible human contact." The Voyager space probes, I think it's fair to > say, will "never" be vulnerable to human contact. They contain tape drives > and tape media, and they are currently electronically connected via NASA's > Deep Space Network. > > Anyway, it depends on what you're trying to accomplish, but lots of > options are available, not necessarily mutually exclusive. > > 2. If you need secure software build and deployment processes (yes, you > do), I suggest contacting my employer. IBM has some super exciting new > capabilities in this area, very cutting edge. They're grounded in > mainframe technologies, whether in your data center, in the public cloud, > or both. Mainframes often pioneer new capabilities that didn't exist in > the entire industry. Here, too, that's what's happening. > > Ransomware is one clearcut demonstration that it doesn't particularly > matter how terrific your data-focused defenses are if you have compromised > applications, for it's applications -- program code -- that process(es) > data. So you've got to approach security challenges holistically. > > > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > > E-Mail: sipp...@sg.ibm.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
Re: Ransoming a mainframe disk farm
SafeGuarded Copy on IBM DS8000 On Fri, Sep 4, 2020, 21:50 Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
Note that measures you instate to protect against a cotntingency you expect might also protect against contingencies you didn't anticipate; ransomware is not the only threat. ObChicago Backup early and often. Test your backups. Have remote backups far enough away that they are not affected by the same disaster. Most shops know the drill, but fewer follow it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Tuesday, September 8, 2020 12:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm Kekronbekron wrote: >Thinking about it ... it would be far simpler (than anti-ransomware >capability in storage, or lock-all behaviour) if there were a RACF >HealthChecker that looks for abnormal enc/dec activity. What 'normal' >is can be learnt from a year's worth of actual enc/dec-related SMF >data. There are tools with capabilities like the ones you're describing. I have a couple comments: 1. There are some excellent ransomware (and similar non-ransomware disaster scenario) defenses available based on "out of band" controls and lockouts. IBM DS8000 SafeGuarded Copy is one such example, a really important one that's the foundation for some other valuable resiliency capabilities. However, I have worked with some organizations that still (also) want to maintain total physical and electronic (wired, wireless) separation for certain data. You can achieve total separation in a few ways, such as physical tape cartridges (usually WORM, preferably encrypted) ejected from tape libraries and vaulted "afar." Of course the costs include elongated Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs), but in some cases the costs are tolerable or at least tolerated. You cannot really keep data completely, absolutely separate if you care about retrieving it. You can only maintain separation with at least one adjective added, such as "physically and electronically separate storage media," which is not the same as "storage media separated from all possible human contact." The Voyager space probes, I think it's fair to say, will "never" be vulnerable to human contact. They contain tape drives and tape media, and they are currently electronically connected via NASA's Deep Space Network. Anyway, it depends on what you're trying to accomplish, but lots of options are available, not necessarily mutually exclusive. 2. If you need secure software build and deployment processes (yes, you do), I suggest contacting my employer. IBM has some super exciting new capabilities in this area, very cutting edge. They're grounded in mainframe technologies, whether in your data center, in the public cloud, or both. Mainframes often pioneer new capabilities that didn't exist in the entire industry. Here, too, that's what's happening. Ransomware is one clearcut demonstration that it doesn't particularly matter how terrific your data-focused defenses are if you have compromised applications, for it's applications -- program code -- that process(es) data. So you've got to approach security challenges holistically. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.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
Re: [OT] Rabies [Was: Ransoming a mainframe disk farm]
It is an interesting note that the rabies protocol is post-exposure. You will get post-exposure treatments on Days 0, 3, 7, and 14. The treatment on day 0 consists of a globulin shot as well as the vaccine. The other three are vaccine only. Joe On Tue, Sep 8, 2020 at 5:46 AM Robert Prins wrote: > On 2020-09-08 10:15, R.S. wrote: > > W dniu 08.09.2020 o 14:09, Robert Prins pisze: > >> On 2020-09-08 07:21, R.S. wrote: > >>> Well, I sustain my words: the only EFFECTIVE way is to prevent. > >>> All other ways are recipes what to do after failure happens, to > minimize the > >>> impact. > >>> > >>> This resembles data loss scenario. What to do when you lost your data? > The > >>> answer is AVOID it. Use RAID arrays, remote copies, backups, archive > copies, > >>> transaction logs... every mentioned thing will not help you when you > lost > >>> your data, it is to help you avoiding data loss. > >>> > >>> BTW: The only method for rabies is to immunization (by vaccination). > There is > >>> no cure. > >> > >> Actually, and obviously this has nothing to do with z/OS, there is a > tiny > >> number of people who recovered from rabies, without vaccine. > > > > Yes, it is off-topic, but "tiny number" is actually ONE. > > Jeanne Giese from US, it was in 2003. Another person was Marciano > Menezes Silva > > from Brasil, but this case is doubtfully documented and considered as > not > > confirmed. All other persons cured using "Milwaukee Protocol" (method > which > > helped Jeanne) died. > > Note, this is not yearly report, this is whole human knowledge since > dark ages. > > Only one person is known to survive rabies. > > Nowadays approx. 15 million people per year are vaccinated. And approx > 20.000 do > > not get vaccination early enough (or at all) and die. No cure. In 1990 > the > > number of victims was approx. 50.000. The main reason of decrease was > action of > > preventive vaccination animals, including wild ones. > > Way more than one: > > > https://abcnews.go.com/Health/california-girl-us-survive-rabies/story?id=13830407 > > Probably should be the final message in this thread! > > Robert > -- > Robert AH Prins > robert.ah.prins(a)gmail.com > The hitchhiking grandfather - https://prino.neocities.org/indez.html > Some REXX code for use on z/OS - > https://prino.neocities.org/zOS/zOS-Tools.html > > -- > 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
[OT] Rabies [Was: Ransoming a mainframe disk farm]
On 2020-09-08 10:15, R.S. wrote: W dniu 08.09.2020 o 14:09, Robert Prins pisze: On 2020-09-08 07:21, R.S. wrote: Well, I sustain my words: the only EFFECTIVE way is to prevent. All other ways are recipes what to do after failure happens, to minimize the impact. This resembles data loss scenario. What to do when you lost your data? The answer is AVOID it. Use RAID arrays, remote copies, backups, archive copies, transaction logs... every mentioned thing will not help you when you lost your data, it is to help you avoiding data loss. BTW: The only method for rabies is to immunization (by vaccination). There is no cure. Actually, and obviously this has nothing to do with z/OS, there is a tiny number of people who recovered from rabies, without vaccine. Yes, it is off-topic, but "tiny number" is actually ONE. Jeanne Giese from US, it was in 2003. Another person was Marciano Menezes Silva from Brasil, but this case is doubtfully documented and considered as not confirmed. All other persons cured using "Milwaukee Protocol" (method which helped Jeanne) died. Note, this is not yearly report, this is whole human knowledge since dark ages. Only one person is known to survive rabies. Nowadays approx. 15 million people per year are vaccinated. And approx 20.000 do not get vaccination early enough (or at all) and die. No cure. In 1990 the number of victims was approx. 50.000. The main reason of decrease was action of preventive vaccination animals, including wild ones. Way more than one: https://abcnews.go.com/Health/california-girl-us-survive-rabies/story?id=13830407 Probably should be the final message in this thread! Robert -- Robert AH Prins robert.ah.prins(a)gmail.com The hitchhiking grandfather - https://prino.neocities.org/indez.html Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
W dniu 08.09.2020 o 14:09, Robert Prins pisze: On 2020-09-08 07:21, R.S. wrote: Well, I sustain my words: the only EFFECTIVE way is to prevent. All other ways are recipes what to do after failure happens, to minimize the impact. This resembles data loss scenario. What to do when you lost your data? The answer is AVOID it. Use RAID arrays, remote copies, backups, archive copies, transaction logs... every mentioned thing will not help you when you lost your data, it is to help you avoiding data loss. BTW: The only method for rabies is to immunization (by vaccination). There is no cure. Actually, and obviously this has nothing to do with z/OS, there is a tiny number of people who recovered from rabies, without vaccine. Yes, it is off-topic, but "tiny number" is actually ONE. Jeanne Giese from US, it was in 2003. Another person was Marciano Menezes Silva from Brasil, but this case is doubtfully documented and considered as not confirmed. All other persons cured using "Milwaukee Protocol" (method which helped Jeanne) died. Note, this is not yearly report, this is whole human knowledge since dark ages. Only one person is known to survive rabies. Nowadays approx. 15 million people per year are vaccinated. And approx 20.000 do not get vaccination early enough (or at all) and die. No cure. In 1990 the number of victims was approx. 50.000. The main reason of decrease was action of preventive vaccination animals, including wild ones. -- Radoslaw Skorupka Lodz, Poland == 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
On 2020-09-08 07:21, R.S. wrote: Well, I sustain my words: the only EFFECTIVE way is to prevent. All other ways are recipes what to do after failure happens, to minimize the impact. This resembles data loss scenario. What to do when you lost your data? The answer is AVOID it. Use RAID arrays, remote copies, backups, archive copies, transaction logs... every mentioned thing will not help you when you lost your data, it is to help you avoiding data loss. BTW: The only method for rabies is to immunization (by vaccination). There is no cure. Actually, and obviously this has nothing to do with z/OS, there is a tiny number of people who recovered from rabies, without vaccine. Robert -- Robert AH Prins robert.ah.prins(a)gmail.com The hitchhiking grandfather - https://prino.neocities.org/indez.html Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Well, I sustain my words: the only EFFECTIVE way is to prevent. All other ways are recipes what to do after failure happens, to minimize the impact. This resembles data loss scenario. What to do when you lost your data? The answer is AVOID it. Use RAID arrays, remote copies, backups, archive copies, transaction logs... every mentioned thing will not help you when you lost your data, it is to help you avoiding data loss. BTW: The only method for rabies is to immunization (by vaccination). There is no cure. -- Radoslaw Skorupka Lodz, Poland W dniu 08.09.2020 o 01:31, Tom Brennan pisze: While I really like your new term, "ransomwared", I have to disagree with the conclusion. Of course we need to try to prevent the attack, but we also need to have some kind of backup to get things at least somewhat back to normal. And that doesn't mean a single backup method for all kinds of data. For example, operating system changes don't happen every day, so as long as you get a system back up, it probably doesn't matter too much if all the PTF's are applied. DB2 is another story if you want something reasonably up-to-date. Hmm... maybe make a deal with the hacker at half price and only get the DB2 datasets back. Just kidding of course. It should be a moral decision to *never* pay any ransom, no matter what the cost to the business. Of course that will never fly in reality. On 9/7/2020 4:34 AM, R.S. wrote: 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. == 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Great notes, thanks! But real geeks know Warp Drive will be invented in 2063 and with that humans can easily catch up with Voyager, well, unless it becomes Vger. Here in the Los Angeles area a few years ago I went to see a guitar player and happened to meet a few guys who engineered and built parts of those probes - specifically the RTG power supplies. I could have listened to them talk about that stuff all evening. On 9/7/2020 9:57 PM, Timothy Sipples wrote: ... The Voyager space probes, I think it's fair to say, will "never" be vulnerable to human contact. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Kekronbekron wrote: >Thinking about it ... it would be far simpler (than anti-ransomware >capability in storage, or lock-all behaviour) if there were a RACF >HealthChecker that looks for abnormal enc/dec activity. What 'normal' >is can be learnt from a year's worth of actual enc/dec-related SMF >data. There are tools with capabilities like the ones you're describing. I have a couple comments: 1. There are some excellent ransomware (and similar non-ransomware disaster scenario) defenses available based on "out of band" controls and lockouts. IBM DS8000 SafeGuarded Copy is one such example, a really important one that's the foundation for some other valuable resiliency capabilities. However, I have worked with some organizations that still (also) want to maintain total physical and electronic (wired, wireless) separation for certain data. You can achieve total separation in a few ways, such as physical tape cartridges (usually WORM, preferably encrypted) ejected from tape libraries and vaulted "afar." Of course the costs include elongated Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs), but in some cases the costs are tolerable or at least tolerated. You cannot really keep data completely, absolutely separate if you care about retrieving it. You can only maintain separation with at least one adjective added, such as "physically and electronically separate storage media," which is not the same as "storage media separated from all possible human contact." The Voyager space probes, I think it's fair to say, will "never" be vulnerable to human contact. They contain tape drives and tape media, and they are currently electronically connected via NASA's Deep Space Network. Anyway, it depends on what you're trying to accomplish, but lots of options are available, not necessarily mutually exclusive. 2. If you need secure software build and deployment processes (yes, you do), I suggest contacting my employer. IBM has some super exciting new capabilities in this area, very cutting edge. They're grounded in mainframe technologies, whether in your data center, in the public cloud, or both. Mainframes often pioneer new capabilities that didn't exist in the entire industry. Here, too, that's what's happening. Ransomware is one clearcut demonstration that it doesn't particularly matter how terrific your data-focused defenses are if you have compromised applications, for it's applications -- program code -- that process(es) data. So you've got to approach security challenges holistically. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Thinking about it ... it would be far simpler (than anti-ransomware capability in storage, or lock-all behaviour) if there were a RACF HealthChecker that looks for abnormal enc/dec activity. What 'normal' is can be learnt from a year's worth of actual enc/dec-related SMF data. - KB ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 9:43 PM, kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > WSL doesn't have anything to do with cloud. > It's just the running of Linux within Windows, using bits of Hyper-V > internally, I think. > > That said, Joe's point about securing this new vector is one to pay attention > to. > And since z/OS is also working on improving/expanding z/OS NFS > implementation.. I'm sure IBM will make it as securable as possible, as > always. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Monday, September 7, 2020 8:56 PM, Steve Thompson ste...@copper.net > wrote: > > > > So, does this mean that a cloud environment is more or less likely to be > > attacked than the same on premise environment? > > Such an attack could cause a major disruption in operations and thinking. > > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct > > mistaks > > > > > On Sep 7, 2020, at 11:20 AM, Joe Monk joemon...@gmail.com wrote: > > > Let me tell you why it is not such a hypothetical problem... > > > As we all know, Microsoft now allows under Windows for Linux, Windows > > > access to Linux datastores. So, imagine I have a mainframe data store > > > mounted as a Linux FS on a Windows box running Windows for Linux. Now, the > > > windows box gets ransom'd ... what happens to the Linux FS mounted on the > > > Windows box? > > > In case you dont know about it: > > > https://docs.microsoft.com/en-us/windows/wsl/install-win10 > > > Joe > > > > > > > On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < > > > > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > > "I see no relationship to the ransomware problem,..." > > > > The whole topic is a hypothetical discussion.. don't know what to say > > > > for > > > > the relation not being understandable. > > > > Just a thought for damage control.. > > > > Obviously, obvious security measures have still let this hypothetical > > > > problem through (either bypassed or less-than-optimal security > > > > measures)... > > > > so fiddling with user accesses at this point is irrelevant. > > > > Whole world knows how to prevent.. but actually doing it is a whole > > > > another matter of tools, processes, capabilities, and such. > > > > > > > > - KB > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Monday, September 7, 2020 7:08 PM, R.S. > > > > r.skoru...@bremultibank.com.pl > > > > wrote: > > > > > > > > > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > > > -- > > 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
Re: Ransoming a mainframe disk farm
Poor product management on the part of the ransomware malefactors. At $50K they might have had a deal. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Monday, September 7, 2020 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm I will tell you that when it happened to my client, the "ransom" was $1million. It was less expensive to lose a days work. in restoring from backups. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
I will tell you that when it happened to my client, the "ransom" was $1million. It was less expensive to lose a days work. in restoring from backups. Joe On Mon, Sep 7, 2020 at 6:53 PM Charles Mills wrote: > > It should be a moral decision to *never* pay any ransom, no matter what > the cost to the business. Of course that will never fly in reality. > > All the InfoSec consultants talk a great game with "never pay" but the > dirty little secret is that many or most do. In many cases it is not just > the organization's data, it is the customers' lives. If you were a bank it > would be great to say "we will never pay" but meanwhile how do your > customers get their grocery money out of your ATMs? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Brennan > Sent: Monday, September 7, 2020 4:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ransoming a mainframe disk farm > > While I really like your new term, "ransomwared", I have to disagree > with the conclusion. Of course we need to try to prevent the attack, > but we also need to have some kind of backup to get things at least > somewhat back to normal. And that doesn't mean a single backup method > for all kinds of data. For example, operating system changes don't > happen every day, so as long as you get a system back up, it probably > doesn't matter too much if all the PTF's are applied. DB2 is another > story if you want something reasonably up-to-date. > > Hmm... maybe make a deal with the hacker at half price and only get the > DB2 datasets back. Just kidding of course. It should be a moral > decision to *never* pay any ransom, no matter what the cost to the > business. Of course that will never fly in reality. > > -- > 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
Re: Ransoming a mainframe disk farm
> It should be a moral decision to *never* pay any ransom, no matter what the > cost to the business. Of course that will never fly in reality. All the InfoSec consultants talk a great game with "never pay" but the dirty little secret is that many or most do. In many cases it is not just the organization's data, it is the customers' lives. If you were a bank it would be great to say "we will never pay" but meanwhile how do your customers get their grocery money out of your ATMs? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Monday, September 7, 2020 4:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm While I really like your new term, "ransomwared", I have to disagree with the conclusion. Of course we need to try to prevent the attack, but we also need to have some kind of backup to get things at least somewhat back to normal. And that doesn't mean a single backup method for all kinds of data. For example, operating system changes don't happen every day, so as long as you get a system back up, it probably doesn't matter too much if all the PTF's are applied. DB2 is another story if you want something reasonably up-to-date. Hmm... maybe make a deal with the hacker at half price and only get the DB2 datasets back. Just kidding of course. It should be a moral decision to *never* pay any ransom, no matter what the cost to the business. Of course that will never fly in reality. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
While I really like your new term, "ransomwared", I have to disagree with the conclusion. Of course we need to try to prevent the attack, but we also need to have some kind of backup to get things at least somewhat back to normal. And that doesn't mean a single backup method for all kinds of data. For example, operating system changes don't happen every day, so as long as you get a system back up, it probably doesn't matter too much if all the PTF's are applied. DB2 is another story if you want something reasonably up-to-date. Hmm... maybe make a deal with the hacker at half price and only get the DB2 datasets back. Just kidding of course. It should be a moral decision to *never* pay any ransom, no matter what the cost to the business. Of course that will never fly in reality. On 9/7/2020 4:34 AM, R.S. wrote: 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
WSL doesn't have anything to do with cloud. It's just the running of Linux within Windows, using bits of Hyper-V internally, I think. That said, Joe's point about securing this new vector is one to pay attention to. And since z/OS is also working on improving/expanding z/OS NFS implementation.. I'm sure IBM will make it as securable as possible, as always. - KB ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 8:56 PM, Steve Thompson wrote: > So, does this mean that a cloud environment is more or less likely to be > attacked than the same on premise environment? > > Such an attack could cause a major disruption in operations and thinking. > > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct > mistaks > > > On Sep 7, 2020, at 11:20 AM, Joe Monk joemon...@gmail.com wrote: > > Let me tell you why it is not such a hypothetical problem... > > As we all know, Microsoft now allows under Windows for Linux, Windows > > access to Linux datastores. So, imagine I have a mainframe data store > > mounted as a Linux FS on a Windows box running Windows for Linux. Now, the > > windows box gets ransom'd ... what happens to the Linux FS mounted on the > > Windows box? > > In case you dont know about it: > > https://docs.microsoft.com/en-us/windows/wsl/install-win10 > > Joe > > > > > On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < > > > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > "I see no relationship to the ransomware problem,..." > > > The whole topic is a hypothetical discussion.. don't know what to say for > > > the relation not being understandable. > > > Just a thought for damage control.. > > > Obviously, obvious security measures have still let this hypothetical > > > problem through (either bypassed or less-than-optimal security > > > measures)... > > > so fiddling with user accesses at this point is irrelevant. > > > Whole world knows how to prevent.. but actually doing it is a whole > > > another matter of tools, processes, capabilities, and such. > > > > > > - KB > > > > > > ‐‐‐ Original Message ‐‐‐ > > > On Monday, September 7, 2020 7:08 PM, R.S. r.skoru...@bremultibank.com.pl > > > wrote: > > > > > > > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > -- > > 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
Re: Ransoming a mainframe disk farm
Use DS8880 SafeGuardCopy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
So, does this mean that a cloud environment is more or less likely to be attacked than the same on premise environment? Such an attack could cause a major disruption in operations and thinking. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Sep 7, 2020, at 11:20 AM, Joe Monk wrote: > > Let me tell you why it is not such a hypothetical problem... > > As we all know, Microsoft now allows under Windows for Linux, Windows > access to Linux datastores. So, imagine I have a mainframe data store > mounted as a Linux FS on a Windows box running Windows for Linux. Now, the > windows box gets ransom'd ... what happens to the Linux FS mounted on the > Windows box? > > In case you dont know about it: > https://docs.microsoft.com/en-us/windows/wsl/install-win10 > > Joe > >> On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < >> 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: >> >> "I see no relationship to the ransomware problem,..." >> >> The whole topic is a hypothetical discussion.. don't know what to say for >> the relation not being understandable. >> Just a thought for damage control.. >> >> Obviously, obvious security measures have still let this hypothetical >> problem through (either bypassed or less-than-optimal security measures)... >> so fiddling with user accesses at this point is irrelevant. >> >> Whole world knows how to prevent.. but actually doing it is a whole >> another matter of tools, processes, capabilities, and such. >> >> - KB >> >> ‐‐‐ Original Message ‐‐‐ >> On Monday, September 7, 2020 7:08 PM, R.S. >> wrote: >> >>> W dniu 07.09.2020 o 14:57, kekronbekron pisze: >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Let me tell you why it is not such a hypothetical problem... As we all know, Microsoft now allows under Windows for Linux, Windows access to Linux datastores. So, imagine I have a mainframe data store mounted as a Linux FS on a Windows box running Windows for Linux. Now, the windows box gets ransom'd ... what happens to the Linux FS mounted on the Windows box? In case you dont know about it: https://docs.microsoft.com/en-us/windows/wsl/install-win10 Joe On Mon, Sep 7, 2020 at 8:47 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > "I see no relationship to the ransomware problem,..." > > The whole topic is a hypothetical discussion.. don't know what to say for > the relation not being understandable. > Just a thought for damage control.. > > Obviously, obvious security measures have still let this hypothetical > problem through (either bypassed or less-than-optimal security measures).. > so fiddling with user accesses at this point is irrelevant. > > Whole world knows how to prevent.. but actually doing it is a whole > another matter of tools, processes, capabilities, and such. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Monday, September 7, 2020 7:08 PM, R.S. > wrote: > > > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > > > > 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 > > > > I see no relationship to the ransomware problem, however in z/OS you can > > "totally lockdown" any network interface you want. Including offline the > > device and chpid. And this is IMHO good for Hollywood movies, not as > > real protection - this "plug out feature" would work ...when? After the > > hacker started encryption, or just two minutes before? Who/what > > recognize suspected activity? What if the activity was phony, just to > > run "plug out feaure"? > > > > My advice: > > > > 1. Only authorized users should have connectivity to the mainframe > > ...and any other resource. No more "any to any" company networks. > Note: > > "authorized" in this point has nothing to do with a mainframe. Just > > Johny the Sysprog can connect to the host, but Jim the secretary > cannot. > > > > 2. Only authorized users can logon. User, password, maybe MFA. Obvious. > > 3. Users are authorized to the resources they need, nothing more. Of > > course we do not talk about READ to SYS1.HELP, but it is good idea to > > not allow APF update to any TSO user. This is typical RACF > > responsibility. Lng story. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > == > > > > 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS > 025237, 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: kont...@mbank.pl. District Court > for the Capital City of Warsaw, 12th Commercial Division of the National > Court Register, KRS 025237, 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
Re: Ransoming a mainframe disk farm
"I see no relationship to the ransomware problem,..." The whole topic is a hypothetical discussion.. don't know what to say for the relation not being understandable. Just a thought for damage control.. Obviously, obvious security measures have still let this hypothetical problem through (either bypassed or less-than-optimal security measures).. so fiddling with user accesses at this point is irrelevant. Whole world knows how to prevent.. but actually doing it is a whole another matter of tools, processes, capabilities, and such. - KB ‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 7:08 PM, R.S. wrote: > W dniu 07.09.2020 o 14:57, kekronbekron pisze: > > > 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 > > I see no relationship to the ransomware problem, however in z/OS you can > "totally lockdown" any network interface you want. Including offline the > device and chpid. And this is IMHO good for Hollywood movies, not as > real protection - this "plug out feature" would work ...when? After the > hacker started encryption, or just two minutes before? Who/what > recognize suspected activity? What if the activity was phony, just to > run "plug out feaure"? > > My advice: > > 1. Only authorized users should have connectivity to the mainframe > ...and any other resource. No more "any to any" company networks. Note: > "authorized" in this point has nothing to do with a mainframe. Just > Johny the Sysprog can connect to the host, but Jim the secretary cannot. > > 2. Only authorized users can logon. User, password, maybe MFA. Obvious. > 3. Users are authorized to the resources they need, nothing more. Of > course we do not talk about READ to SYS1.HELP, but it is good idea to > not allow APF update to any TSO user. This is typical RACF > responsibility. Lng story. > > -- > Radoslaw Skorupka > Lodz, Poland > > == > > 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, > 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: kont...@mbank.pl. District Court for > the Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, 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 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
Re: Ransoming a mainframe disk farm
W dniu 07.09.2020 o 14:57, kekronbekron pisze: 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 I see no relationship to the ransomware problem, however in z/OS you can "totally lockdown" any network interface you want. Including offline the device and chpid. And this is IMHO good for Hollywood movies, not as real protection - this "plug out feature" would work ...when? After the hacker started encryption, or just two minutes before? Who/what recognize suspected activity? What if the activity was phony, just to run "plug out feaure"? My advice: 1. Only authorized users should have connectivity to the mainframe ...and any other resource. No more "any to any" company networks. Note: "authorized" in this point has nothing to do with a mainframe. Just Johny the Sysprog can connect to the host, but Jim the secretary cannot. 2. Only authorized users can logon. User, password, maybe MFA. Obvious. 3. Users are authorized to the resources they need, nothing more. Of course we do not talk about READ to SYS1.HELP, but it is good idea to not allow APF update to any TSO user. This is typical RACF responsibility. Lng story. -- Radoslaw Skorupka Lodz, Poland == 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
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. 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,%, 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. > > > --
Re: Ransoming a mainframe disk farm
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,%, 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 robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 5
Re: Ransoming a mainframe disk farm
Or you just write protect all of your backups on virtual tape. Brian On Sat, 5 Sep 2020 15:38:04 +, 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 >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 >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 s
Re: Ransoming a mainframe disk farm
NO, but you can very easily IPL those utilities from virtual tape. In fact, one of the first things I do when I enter a site to maintain it is create a single pack IPL volume of their running system and DFdss it to virtual tape and I make (several) copies of the various IPLable utilities on separate tapes. I have other stuff that I do for the catalogs which is probably also overkill. I also have ZZSA ready to go on a DASD volume and a recoverable virtual tape. I have never needed to revert to using the SAIPL volume or ZZSA but I test it quarterly anyway. Brian On Fri, 4 Sep 2020 19:53:11 +, Gibney, Dave wrote: >You can IPL Standalone DSS or FDR from CD > >> ---O-Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Jesse 1 Robinson >> Sent: Friday, September 04, 2020 11:51 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Ransoming a mainframe disk farm >> >> 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
Re: Ransoming a mainframe disk farm
If it's on the network then you know someone can find a way in, and once they are in then all bets are off. Given the newer technology that has been, and is being, developed to crack passwords it is only a matter of when and not if. Are WORMs really protected if they are in a virtual storage subsystem? Aren't they really just artifacts that have been defined as WORM but in reality are only protected by the software in the subsystem? Paranoia is only false if you know that no one is after you - but can you be sure. Lionel B. Dyck < Website: https://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
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 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 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
Re: Ransoming a mainframe disk farm
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 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 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
Re: Ransoming a mainframe disk farm
We once had a database so valuable that it was mirrored to a remote site where 8, 16, and 24 hour PIT copies of it were made. We could do forward recovery from tape if needed. This was more to protect against an application trashing the data than anything else. It was hoped that data corruption would be noticed fairly quickly. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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
Re: Ransoming a mainframe disk farm
😉 . . 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 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, September 4, 2020 5:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Ransoming a mainframe disk farm CAUTION EXTERNAL EMAIL "Bill Gates and the FBI say it is the worst virus ever. Forward this to everyone in your address book." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Friday, September 4, 2020 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm Ha ha: "Hello, Iron Mountain? This is the CIO. We've discovered a terrible computer virus that only exists on physical tape. I need you to take every tape you can find to the shredder immediately. Wear gloves and a mask - you don't want to catch it. Hurry!!" On 9/4/2020 3:23 PM, Seymour J Metz wrote: > If you mirror a backup to a remote site, unload the tape and ship it > to a vault, it would take a clever cracker to ovevewrite it ;-) > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on > behalf of Tom Brennan > Sent: Friday, September 4, 2020 5:31 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ransoming a mainframe disk farm > > Reminds me of a "Tech Support" (I think) magazine article I read many > years ago that started out with something like, "The company > datacenter has lost all its data, including all backups. A > disgruntled employee with full access ran weekend jobs which overwrote > all tapes and disk backups, and then finally overwrote the running > disk volumes. The company cannot survive." Then it went on to say > this didn't really happen, but was more of a call to action. It sure > caught my attention for the first few paragraphs! > > By coincidence, yesterday I was at a datacenter implementing a > temporary Linux server running MinIO which is an S3 Object Store > server that I hope can simulate things like cloud processing for a proof of > concept. > With some extra VTS microcode (still in beta I heard?), they tell me a > TS7770 can dump tape data onto a remote cloud server, to be restored > if needed by the same or any other TS7770. So we're going to run a > test of that in a week or two, I expect. > > Now I assume that ransomware, or a disgruntled employee, could know > enough about a site to overwrite all "tapes" in the VTS, including any > remote cloud objects - unless there's a way to make those remote files > write-once. Don't know yet. > > On 9/4/2020 11:50 AM, Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
"Bill Gates and the FBI say it is the worst virus ever. Forward this to everyone in your address book." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Friday, September 4, 2020 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm Ha ha: "Hello, Iron Mountain? This is the CIO. We've discovered a terrible computer virus that only exists on physical tape. I need you to take every tape you can find to the shredder immediately. Wear gloves and a mask - you don't want to catch it. Hurry!!" On 9/4/2020 3:23 PM, Seymour J Metz wrote: > If you mirror a backup to a remote site, unload the tape and ship it to a > vault, it would take a clever cracker to ovevewrite it ;-) > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > Tom Brennan > Sent: Friday, September 4, 2020 5:31 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ransoming a mainframe disk farm > > Reminds me of a "Tech Support" (I think) magazine article I read many > years ago that started out with something like, "The company datacenter > has lost all its data, including all backups. A disgruntled employee > with full access ran weekend jobs which overwrote all tapes and disk > backups, and then finally overwrote the running disk volumes. The > company cannot survive." Then it went on to say this didn't really > happen, but was more of a call to action. It sure caught my attention > for the first few paragraphs! > > By coincidence, yesterday I was at a datacenter implementing a temporary > Linux server running MinIO which is an S3 Object Store server that I > hope can simulate things like cloud processing for a proof of concept. > With some extra VTS microcode (still in beta I heard?), they tell me a > TS7770 can dump tape data onto a remote cloud server, to be restored if > needed by the same or any other TS7770. So we're going to run a test of > that in a week or two, I expect. > > Now I assume that ransomware, or a disgruntled employee, could know > enough about a site to overwrite all "tapes" in the VTS, including any > remote cloud objects - unless there's a way to make those remote files > write-once. Don't know yet. > > On 9/4/2020 11:50 AM, Jesse 1 Robinson 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ransoming a mainframe disk farm
Ha ha: "Hello, Iron Mountain? This is the CIO. We've discovered a terrible computer virus that only exists on physical tape. I need you to take every tape you can find to the shredder immediately. Wear gloves and a mask - you don't want to catch it. Hurry!!" On 9/4/2020 3:23 PM, Seymour J Metz wrote: If you mirror a backup to a remote site, unload the tape and ship it to a vault, it would take a clever cracker to ovevewrite it ;-) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Friday, September 4, 2020 5:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm Reminds me of a "Tech Support" (I think) magazine article I read many years ago that started out with something like, "The company datacenter has lost all its data, including all backups. A disgruntled employee with full access ran weekend jobs which overwrote all tapes and disk backups, and then finally overwrote the running disk volumes. The company cannot survive." Then it went on to say this didn't really happen, but was more of a call to action. It sure caught my attention for the first few paragraphs! By coincidence, yesterday I was at a datacenter implementing a temporary Linux server running MinIO which is an S3 Object Store server that I hope can simulate things like cloud processing for a proof of concept. With some extra VTS microcode (still in beta I heard?), they tell me a TS7770 can dump tape data onto a remote cloud server, to be restored if needed by the same or any other TS7770. So we're going to run a test of that in a week or two, I expect. Now I assume that ransomware, or a disgruntled employee, could know enough about a site to overwrite all "tapes" in the VTS, including any remote cloud objects - unless there's a way to make those remote files write-once. Don't know yet. On 9/4/2020 11:50 AM, Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
Maze Ransomware ... 'nuff said. Thank goodness for site-to-site replication. Joe On Fri, Sep 4, 2020 at 3:40 PM Jesse 1 Robinson wrote: > Joe, am I reading that this situation actually happened to your VTL > customer??? > > . > . > 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 > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Joe Monk > Sent: Friday, September 4, 2020 12:10 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Ransoming a mainframe disk farm > > CAUTION EXTERNAL EMAIL > > Skip, > > I will tell you what saved one of my customers. When they use a VTL, they > replicated that VTL to another site. So, when some files got encrypted via > ransomware, they were able to quickly replicate the files back and re-boot. > > Joe > > On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson > 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
Re: Ransoming a mainframe disk farm
If you mirror a backup to a remote site, unload the tape and ship it to a vault, it would take a clever cracker to ovevewrite it ;-) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Friday, September 4, 2020 5:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ransoming a mainframe disk farm Reminds me of a "Tech Support" (I think) magazine article I read many years ago that started out with something like, "The company datacenter has lost all its data, including all backups. A disgruntled employee with full access ran weekend jobs which overwrote all tapes and disk backups, and then finally overwrote the running disk volumes. The company cannot survive." Then it went on to say this didn't really happen, but was more of a call to action. It sure caught my attention for the first few paragraphs! By coincidence, yesterday I was at a datacenter implementing a temporary Linux server running MinIO which is an S3 Object Store server that I hope can simulate things like cloud processing for a proof of concept. With some extra VTS microcode (still in beta I heard?), they tell me a TS7770 can dump tape data onto a remote cloud server, to be restored if needed by the same or any other TS7770. So we're going to run a test of that in a week or two, I expect. Now I assume that ransomware, or a disgruntled employee, could know enough about a site to overwrite all "tapes" in the VTS, including any remote cloud objects - unless there's a way to make those remote files write-once. Don't know yet. On 9/4/2020 11:50 AM, Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
Reminds me of a "Tech Support" (I think) magazine article I read many years ago that started out with something like, "The company datacenter has lost all its data, including all backups. A disgruntled employee with full access ran weekend jobs which overwrote all tapes and disk backups, and then finally overwrote the running disk volumes. The company cannot survive." Then it went on to say this didn't really happen, but was more of a call to action. It sure caught my attention for the first few paragraphs! By coincidence, yesterday I was at a datacenter implementing a temporary Linux server running MinIO which is an S3 Object Store server that I hope can simulate things like cloud processing for a proof of concept. With some extra VTS microcode (still in beta I heard?), they tell me a TS7770 can dump tape data onto a remote cloud server, to be restored if needed by the same or any other TS7770. So we're going to run a test of that in a week or two, I expect. Now I assume that ransomware, or a disgruntled employee, could know enough about a site to overwrite all "tapes" in the VTS, including any remote cloud objects - unless there's a way to make those remote files write-once. Don't know yet. On 9/4/2020 11:50 AM, Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
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 on behalf of Tony Thigpen Sent: Friday, September 4, 2020 3:54 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 > 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
Re: Ransoming a mainframe disk farm
Your devices should still be there. Issue a mount for the volume in a specific device. You might need to access the Virtual Library's manual mount functions > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jesse 1 Robinson > Sent: Friday, September 04, 2020 1:21 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ransoming a mainframe disk farm > > I did not know that CD could be used for standalone restore. However, how > do I process my volume dumps? They also live only in virtual. > > . > . > 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 > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Friday, September 4, 2020 12:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Ransoming a mainframe disk farm > > CAUTION EXTERNAL EMAIL > > You can IPL Standalone DSS or FDR from CD > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Jesse 1 Robinson > > Sent: Friday, September 04, 2020 11:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Ransoming a mainframe disk farm > > > > 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
Re: Ransoming a mainframe disk farm
Joe, am I reading that this situation actually happened to your VTL customer??? . . 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 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Friday, September 4, 2020 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Ransoming a mainframe disk farm CAUTION EXTERNAL EMAIL Skip, I will tell you what saved one of my customers. When they use a VTL, they replicated that VTL to another site. So, when some files got encrypted via ransomware, they were able to quickly replicate the files back and re-boot. Joe On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
Did you see the SHARE demo of this that Chad did as a Security keynote a couple of years ago? (There was a suit sitting behind me the whole time mumbling "oh Jesus. Oh Jesus. Oh Jesus.") He demoed the whole process. They were separate pieces. He said "I am not crazy enough to actually integrate them." If you are inside a PC it is easy to detect TN3270 connections. Among other things then tend to be more persistent than most. It is then fairly easy to do your first steps via an IND$FILE type connection, and then to submit the job. You don't need to know every dataset name -- just the key ones. Dataset discovery is fairly straightforward. Don't underestimate the tools that are out there, or the cleverness and patience of the bad guys. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Friday, September 4, 2020 12:55 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 > robin...@sce.com > > > -- > For IBM-MAIN subscribe / signoff / archive
Re: Ransoming a mainframe disk farm
I did not know that CD could be used for standalone restore. However, how do I process my volume dumps? They also live only in virtual. . . 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 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Friday, September 4, 2020 12:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Ransoming a mainframe disk farm CAUTION EXTERNAL EMAIL You can IPL Standalone DSS or FDR from CD > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jesse 1 Robinson > Sent: Friday, September 04, 2020 11:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Ransoming a mainframe disk farm > > 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
Re: Ransoming a mainframe disk farm
I'm a tiny bit of an expert in ransomware and not much of an expert in mainframe backup strategies, but here goes ... Just kind of a conceptual thought ... It seems to me the big advantage of tape (in this scenario) is the time lag. It is not perfectly up-to-the-minute, and therefore is "good" and not encrypted. It would be great if one had a mirrored disk farm that was always a couple of days behind real-time. With any luck you would have a usable system and usable data, albeit a day or two out of date. I do think it is really good to be thinking about these things. I think the mainframe ransomware scenario is more likely than we might like to think. Mainframes are really, really good at high-speed data encryption. And as Chad "Bigendian Smalls" Rikansrud observed: "you know the difference between Pervasive Encryption and Ransomware?" Answer: who has the keys. Why did Willie Sutton rob banks? "Because that's where the money is." If you were a Ransomware perpetrator, wouldn't you want to go where the really valuable data is? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Friday, September 4, 2020 11:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ransoming a mainframe disk farm 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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
Re: Ransoming a mainframe disk farm
You can IPL Standalone DSS or FDR from CD > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jesse 1 Robinson > Sent: Friday, September 04, 2020 11:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Ransoming a mainframe disk farm > > 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
Re: Ransoming a mainframe disk farm
Unless the migration away from Physical Tape was done by people completely unfamiliar with Mainframe processing Change 'tape' to 'Virtual Tape Subsystem Objects' Although we used the DRVendor's floor system to run the restore, we could have had them 'mount' our DR z/VM or DR z/OS system image to restore first. But we did the whole DR exercise without Physical Tapes. DRVendor was more than 300 miles away. /Tom Kern On 9/4/20 2:50 PM, Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
Skip, I will tell you what saved one of my customers. When they use a VTL, they replicated that VTL to another site. So, when some files got encrypted via ransomware, they were able to quickly replicate the files back and re-boot. Joe On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson 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
Re: Ransoming a mainframe disk farm
Retire? Doug Fuerst d...@bkassociates.net -- Original Message -- From: "Jesse 1 Robinson" To: IBM-MAIN@listserv.ua.edu Sent: 04-Sep-20 14:50:50 Subject: Ransoming a mainframe disk farm 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
Ransoming a mainframe disk farm
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
