Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
Which tools? Some tools on the PC are user hostile; some tools on z/OS are user hostile. A security bug in Apache is a security bug in Apache. Keep up to date on security fixes, regardless of platform. I can't speak to TPF, and my DOS and VM experience is too old to be relevant. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Friday, July 26, 2019 10:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL] [Default] On 7 Jun 2019 09:26:29 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >How many vulnerabilities have you seen that did not come down to people? Those >sysprogs are just the tip of the iceberg as far as configuration, enforcement, >management, policy, procedure, protocol and training vulnerabilities are >concerned. Yes, I've seen code vulnerabilities, but they're ju8st noise >compared to the other isswues. > >I come at this from the other end; when I had RACF SPECIAL I refused to give >myself UID(0) because it was an unnecessary risk. Are the tools to set up and administer z/OS systems as easy to use as those available for setting up and administering Linux systems? Unix system? Windows systems? Is an Apache server running on a z series mainframe any more secure than one running on Linux? To the extent Mainframes are available from other vendors such as Unisys, how does their security compare? Is z/TPF as secure as z/OS? How about z/VM and z/VSE? Clark Morris -- 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: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
[Default] On 7 Jun 2019 09:26:29 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >How many vulnerabilities have you seen that did not come down to people? Those >sysprogs are just the tip of the iceberg as far as configuration, enforcement, >management, policy, procedure, protocol and training vulnerabilities are >concerned. Yes, I've seen code vulnerabilities, but they're ju8st noise >compared to the other isswues. > >I come at this from the other end; when I had RACF SPECIAL I refused to give >myself UID(0) because it was an unnecessary risk. Are the tools to set up and administer z/OS systems as easy to use as those available for setting up and administering Linux systems? Unix system? Windows systems? Is an Apache server running on a z series mainframe any more secure than one running on Linux? To the extent Mainframes are available from other vendors such as Unisys, how does their security compare? Is z/TPF as secure as z/OS? How about z/VM and z/VSE? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
W dniu 2019-06-12 o 18:29, Wayne Driscoll pisze: I was one of the developers for Deadbolt, and while we were able to get the product into a small number of installations as an "alpha" state release, the project was cancelled in early 2008. ... and I remember your name from that time ;-) Personally I thought that someone tries to tilt at windmills, however I saw and enterpreneur was one of BMC founders, so I changed my opinion. Nowadays, from time perspective I again think it was doomed to failure from business point of view, despite of technical (dis)advantages. BTW: Can you tell us how many people were involved in the project? It's interesting how many people (man days) would it take to create ESM from scratch. Regards -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
I was one of the developers for Deadbolt, and while we were able to get the product into a small number of installations as an "alpha" state release, the project was cancelled in early 2008. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, June 11, 2019 1:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls I have never found much barrier to entry with the IBM Business Partner process. The HUGE obstacle is customer inertia and conservatism. Customers may complain about software costs, but they are the big barriers to entry for small competitors. At my former employer we had customers say specifically "we love your product but we are not taking on any new software vendors." (In some cases you could overcome that by partnering with a reseller.) I would not want to be out there pitching "my ESM from Mills & Associates is way superior to RACF, Mr. Wells Fargo or Mr. Fidelity or whatever. You should drop RACF and install the Mills & Associates ESM." There is a concept in software marketing called "stickiness." A search engine has zero stickiness. If a better search engine came along tomorrow you would start using it in a heartbeat. An ESM is way sticky. Even if I could sell Mr. Fargo on the superiority of my ESM, who is going to migrate all their RACF rules and administrative processes and TEST them? Barry tried (or is still trying?) with a product (or prototype or concept) called DEADBOLT. https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibmsystemsmag.com%2Fmainframe%2Ftrends%2Fztalk%2Fbarry-schrager%2Fdata=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C3dccc79ac19e457f709508d6ee9a6b83%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636958744343975330sdata=UJAwz6fOG%2BZrEIO%2FqUTAMl1nUJyyHSzxGrm4L2qb5GQ%3Dreserved=0 https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dignus.com%2Fsuccess_stories%2FJME%2Fpaper.htmldata=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C3dccc79ac19e457f709508d6ee9a6b83%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636958744343975330sdata=K4dbKJR1i85k6dd9246I7t4FNVS47OksBYu4UHlOV4Y%3Dreserved=0 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, June 11, 2019 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls On Tue, Jun 11, 2019 at 11:26 AM Bob Bridges wrote: > If that's what it stands for I should think those aren't just the big > three but the ~only~ three. At least, I've never heard of any others. > Which is odd, when you think about it; surely there's someone out > there wanting to break into the market? So says my capitalist > assumptions. But apparently not. > Most likely the entry cost. Developing z/OS software is _expensive_. I don't know, but when I looked a couple of years ago, the zPDT was something like $5000 / year with annual renewal. And you need to be approved by IBM as a "Business Partner". That is a stiff barrier to entry, IMO. I know some business people here have a zPDT system, but I doubt that Phoenix Software would really want to go up against IBM and CA for that market. Also, unlike a productivity tool such as (E)JES, an ESM is (or should be) "business critical" for protection. To convince a company to go with a "new & unknown" product in this era of PHI, HIPAA, GDPR, and so on is so unlikely as to be silly to even consider. Better to go with products such as (E)JES (Phoenix Software) or Systems/ASM (Dignus) which, I feel, are more likely to be considered without the company auditors having a fit. The reason I love Linux is the _zero_ cost of the GNU and other software. Basically I only pay for the hardware and electricity. Of course, I am not a software developer, just a bit of a dilettante so far as programming is concerned. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* Nearly all men can stand adversity. If you want to test a man's > character, give him power. -Abraham Lincoln */ > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Pommier, Rex > Sent: Thursday, May 30, 2019 11:22 > > I have been under the impression it stands for External Security > Manager, of which the "big 3" would be RACF, ACF2, Top Secret. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Brennan > Sent: Thursday, May 30, 2019 10:21 AM > > I've seen the acronym ESM a few times in this thread. I'll assume > that means "Enterprise Security Management&q
Re: Just how secure are mainframes? | Trevor Eddolls
There were other ESMs. I'm aware of at least two. One was Deadbolt from JMenterprises (or so). One of Deadbolt developers is member of IBM-MAIN (maybe more, I know one). The second product was PIES. It was polish product. I don't think it was in use outside of Poland. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-11 o 18:25, Bob Bridges pisze: If that's what it stands for I should think those aren't just the big three but the ~only~ three. At least, I've never heard of any others. Which is odd, when you think about it; surely there's someone out there wanting to break into the market? So says my capitalist assumptions. But apparently not. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Nearly all men can stand adversity. If you want to test a man's character, give him power. -Abraham Lincoln */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 30, 2019 11:22 I have been under the impression it stands for External Security Manager, of which the "big 3" would be RACF, ACF2, Top Secret. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Thursday, May 30, 2019 10:21 AM I've seen the acronym ESM a few times in this thread. I'll assume that means "Enterprise Security Management", and I'll guess it refers to security processes (not RACF), such as assigning userid's, making sure people have just the access they need, periodic audits, etc. Am I even close? -- 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: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
I have never found much barrier to entry with the IBM Business Partner process. The HUGE obstacle is customer inertia and conservatism. Customers may complain about software costs, but they are the big barriers to entry for small competitors. At my former employer we had customers say specifically "we love your product but we are not taking on any new software vendors." (In some cases you could overcome that by partnering with a reseller.) I would not want to be out there pitching "my ESM from Mills & Associates is way superior to RACF, Mr. Wells Fargo or Mr. Fidelity or whatever. You should drop RACF and install the Mills & Associates ESM." There is a concept in software marketing called "stickiness." A search engine has zero stickiness. If a better search engine came along tomorrow you would start using it in a heartbeat. An ESM is way sticky. Even if I could sell Mr. Fargo on the superiority of my ESM, who is going to migrate all their RACF rules and administrative processes and TEST them? Barry tried (or is still trying?) with a product (or prototype or concept) called DEADBOLT. http://ibmsystemsmag.com/mainframe/trends/ztalk/barry-schrager/ http://www.dignus.com/success_stories/JME/paper.html Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, June 11, 2019 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls On Tue, Jun 11, 2019 at 11:26 AM Bob Bridges wrote: > If that's what it stands for I should think those aren't just the big > three but the ~only~ three. At least, I've never heard of any others. > Which is odd, when you think about it; surely there's someone out there > wanting to break into the market? So says my capitalist assumptions. But > apparently not. > Most likely the entry cost. Developing z/OS software is _expensive_. I don't know, but when I looked a couple of years ago, the zPDT was something like $5000 / year with annual renewal. And you need to be approved by IBM as a "Business Partner". That is a stiff barrier to entry, IMO. I know some business people here have a zPDT system, but I doubt that Phoenix Software would really want to go up against IBM and CA for that market. Also, unlike a productivity tool such as (E)JES, an ESM is (or should be) "business critical" for protection. To convince a company to go with a "new & unknown" product in this era of PHI, HIPAA, GDPR, and so on is so unlikely as to be silly to even consider. Better to go with products such as (E)JES (Phoenix Software) or Systems/ASM (Dignus) which, I feel, are more likely to be considered without the company auditors having a fit. The reason I love Linux is the _zero_ cost of the GNU and other software. Basically I only pay for the hardware and electricity. Of course, I am not a software developer, just a bit of a dilettante so far as programming is concerned. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* Nearly all men can stand adversity. If you want to test a man's > character, give him power. -Abraham Lincoln */ > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pommier, Rex > Sent: Thursday, May 30, 2019 11:22 > > I have been under the impression it stands for External Security Manager, > of which the "big 3" would be RACF, ACF2, Top Secret. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Brennan > Sent: Thursday, May 30, 2019 10:21 AM > > I've seen the acronym ESM a few times in this thread. I'll assume that > means "Enterprise Security Management", and I'll guess it refers to > security processes (not RACF), such as assigning userid's, making sure > people have just the access they need, periodic audits, etc. > > Am I even close? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- 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: Just how secure are mainframes? | Trevor Eddolls
On Tue, Jun 11, 2019 at 11:26 AM Bob Bridges wrote: > If that's what it stands for I should think those aren't just the big > three but the ~only~ three. At least, I've never heard of any others. > Which is odd, when you think about it; surely there's someone out there > wanting to break into the market? So says my capitalist assumptions. But > apparently not. > Most likely the entry cost. Developing z/OS software is _expensive_. I don't know, but when I looked a couple of years ago, the zPDT was something like $5000 / year with annual renewal. And you need to be approved by IBM as a "Business Partner". That is a stiff barrier to entry, IMO. I know some business people here have a zPDT system, but I doubt that Phoenix Software would really want to go up against IBM and CA for that market. Also, unlike a productivity tool such as (E)JES, an ESM is (or should be) "business critical" for protection. To convince a company to go with a "new & unknown" product in this era of PHI, HIPAA, GDPR, and so on is so unlikely as to be silly to even consider. Better to go with products such as (E)JES (Phoenix Software) or Systems/ASM (Dignus) which, I feel, are more likely to be considered without the company auditors having a fit. The reason I love Linux is the _zero_ cost of the GNU and other software. Basically I only pay for the hardware and electricity. Of course, I am not a software developer, just a bit of a dilettante so far as programming is concerned. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* Nearly all men can stand adversity. If you want to test a man's > character, give him power. -Abraham Lincoln */ > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pommier, Rex > Sent: Thursday, May 30, 2019 11:22 > > I have been under the impression it stands for External Security Manager, > of which the "big 3" would be RACF, ACF2, Top Secret. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Brennan > Sent: Thursday, May 30, 2019 10:21 AM > > I've seen the acronym ESM a few times in this thread. I'll assume that > means "Enterprise Security Management", and I'll guess it refers to > security processes (not RACF), such as assigning userid's, making sure > people have just the access they need, periodic audits, etc. > > Am I even close? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
If that's what it stands for I should think those aren't just the big three but the ~only~ three. At least, I've never heard of any others. Which is odd, when you think about it; surely there's someone out there wanting to break into the market? So says my capitalist assumptions. But apparently not. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Nearly all men can stand adversity. If you want to test a man's character, give him power. -Abraham Lincoln */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 30, 2019 11:22 I have been under the impression it stands for External Security Manager, of which the "big 3" would be RACF, ACF2, Top Secret. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Thursday, May 30, 2019 10:21 AM I've seen the acronym ESM a few times in this thread. I'll assume that means "Enterprise Security Management", and I'll guess it refers to security processes (not RACF), such as assigning userid's, making sure people have just the access they need, periodic audits, etc. Am I even close? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
How many vulnerabilities have you seen that did not come down to people? Those sysprogs are just the tip of the iceberg as far as configuration, enforcement, management, policy, procedure, protocol and training vulnerabilities are concerned. Yes, I've seen code vulnerabilities, but they're ju8st noise compared to the other isswues. I come at this from the other end; when I had RACF SPECIAL I refused to give myself UID(0) because it was an unnecessary risk. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Thursday, June 6, 2019 4:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL] Seymour, i have seen sysprogs in few sites that are convinced that you need read access to racf / tss db in order to be an admin or even for query only. ITscahk בתאריך יום ה׳, 6 ביוני 2019, 19:31, מאת Seymour J Metz : > ITYM any shop that allows general user access to the RACF DB deserves to > be cracked. There's nothing magic about IEBGENER. Access to sensitive > information should be limited to those who need it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Jones, Phil <02379a6d81f2-dmarc-requ...@listserv.ua.edu> > Sent: Wednesday, June 5, 2019 9:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > [SEC=UNOFFICIAL] > > At the risk of being controversial, I think that any z/OS site that allows > general utility access to the RACF DB almost DESERVES to be hacked... > > Regards; Phil J. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of R.S. > Sent: Thursday, 6 June 2019 2:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: > > Sory to inform you: there are such SVCs available for download. I > > think there is one on the cbttape . > > While such code is available for download it is not available for install. > Otherwise we talk about mistakes in configurations => human problem, not > platform weakness. > > BTW: I know very dangerous tool for hacking RACFdb and passwords: > IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 > content directly to some hack site and voila. > > -- > 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, > http://secure-web.cisco.com/155_aQOAoYRplWsWRrv0Iz9uLpzX7mTLneLQ8ackg2-7lXx5ujQdijuIMoETyiMbzgjTFCJa2J3NXb9EMEnPGmdfY2GgS7Bx6YWmKwA7D0OecYPlYtL-mw_lbfL0q2ngrXUNYxVbK1BHFkORXi79SprF9LDKOLsqXBEjByUck_pvgN-tbnRPa9M7zkvFO0A_CObnOwjlVO-yS8w-ERPbmnjxJyvkEyrI9lOCpzGYB3O4VuVeVTxd7cXhWPJaSrh6PA6dLxEYYq5Wf5R9iKLa7h805Nu5RBSnPGz1gORb-dPX-iZa9G64PoezBCllRK62jIW7OYD6MswRwZeQ_Lrx6U8RmNCRQGZq_cf96EU57zm__JzBoVPsOt24oXXETboCj-eu9OsNrN_zqKP0VDgbRzMEacqPR8_7_8DSQVAMpy-1XZ6CytpCMOa7t0fQJZxDz/http%3A%2F%2Fwww.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.2018 r. wynosi 169.248.488 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, > http://secure-web.cisco.com/155_aQOAoYRplWsWRrv0Iz9uLpzX7mTLneLQ8ackg2-7lXx5ujQdijuIMoETyiMbzgjTFCJa2J3NXb9EMEnPGmdfY2GgS7Bx6YWmKwA7D0OecYPlYtL-mw_lbfL0q2ngrXUNYxVbK1BHFkORXi79SprF9LDKOLsqXBEjByUck_pvgN-tbnRPa9M7zkvFO0A_CObnOwjlVO-yS8w-ERPbmnjxJyvkEyrI9lOCpz
Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
And this is telling. What did you propose? New product to make the system less vulnerable or just suggest proper configuration? What's the solution for the case? Why almost all cases mentioned here are like that, that means some misconfiguration done by mistake or due to lack of knowledge? Why any other case falls to category "I know, but I can't tell you any details, but you should be worry"? IEBGENER (+accessREAD), APF, SVC - those are regular system things, none of them is insecure, each of them can be misused. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-06 o 22:30, ITschak Mugzach pisze: Seymour, i have seen sysprogs in few sites that are convinced that you need read access to racf / tss db in order to be an admin or even for query only. ITscahk בתאריך יום ה׳, 6 ביוני 2019, 19:31, מאת Seymour J Metz : ITYM any shop that allows general user access to the RACF DB deserves to be cracked. There's nothing magic about IEBGENER. Access to sensitive information should be limited to those who need it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 == 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
Unfortunately, I have also seen a few (and fixed them; some people even complained about it!). It's not just people, it's also 'process'. Regards; Phil . -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, 6 June 2019 6:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL] Unfortunately I have seen few. However I fixed it (that was part of my role there). And again it is not about paltform strength, it is about people. However this is the market for some companies. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-06 o 03:33, Bill Johnson pisze: > Agree 100% and have never seen a shop that does. > > > Sent from Yahoo Mail for iPhone > > > On Wednesday, June 5, 2019, 9:29 PM, Jones, Phil > <02379a6d81f2-dmarc-requ...@listserv.ua.edu> wrote: > > At the risk of being controversial, I think that any z/OS site that allows > general utility access to the RACF DB almost DESERVES to be hacked... > > Regards; Phil J. == 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** IMPORTANT: This e-mail is for the use of the intended recipient only and may contain information that is confidential, commercially valuable and/or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the sender immediately and delete all electronic and hard copies of this transmission together with any attachments. Please consider the environment before printing this e-mail ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
Seymour, i have seen sysprogs in few sites that are convinced that you need read access to racf / tss db in order to be an admin or even for query only. ITscahk בתאריך יום ה׳, 6 ביוני 2019, 19:31, מאת Seymour J Metz : > ITYM any shop that allows general user access to the RACF DB deserves to > be cracked. There's nothing magic about IEBGENER. Access to sensitive > information should be limited to those who need it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Jones, Phil <02379a6d81f2-dmarc-requ...@listserv.ua.edu> > Sent: Wednesday, June 5, 2019 9:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > [SEC=UNOFFICIAL] > > At the risk of being controversial, I think that any z/OS site that allows > general utility access to the RACF DB almost DESERVES to be hacked... > > Regards; Phil J. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of R.S. > Sent: Thursday, 6 June 2019 2:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: > > Sory to inform you: there are such SVCs available for download. I > > think there is one on the cbttape . > > While such code is available for download it is not available for install. > Otherwise we talk about mistakes in configurations => human problem, not > platform weakness. > > BTW: I know very dangerous tool for hacking RACFdb and passwords: > IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 > content directly to some hack site and voila. > > -- > 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, > http://secure-web.cisco.com/155_aQOAoYRplWsWRrv0Iz9uLpzX7mTLneLQ8ackg2-7lXx5ujQdijuIMoETyiMbzgjTFCJa2J3NXb9EMEnPGmdfY2GgS7Bx6YWmKwA7D0OecYPlYtL-mw_lbfL0q2ngrXUNYxVbK1BHFkORXi79SprF9LDKOLsqXBEjByUck_pvgN-tbnRPa9M7zkvFO0A_CObnOwjlVO-yS8w-ERPbmnjxJyvkEyrI9lOCpzGYB3O4VuVeVTxd7cXhWPJaSrh6PA6dLxEYYq5Wf5R9iKLa7h805Nu5RBSnPGz1gORb-dPX-iZa9G64PoezBCllRK62jIW7OYD6MswRwZeQ_Lrx6U8RmNCRQGZq_cf96EU57zm__JzBoVPsOt24oXXETboCj-eu9OsNrN_zqKP0VDgbRzMEacqPR8_7_8DSQVAMpy-1XZ6CytpCMOa7t0fQJZxDz/http%3A%2F%2Fwww.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.2018 r. wynosi 169.248.488 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, > http://secure-web.cisco.com/155_aQOAoYRplWsWRrv0Iz9uLpzX7mTLneLQ8ackg2-7lXx5ujQdijuIMoETyiMbzgjTFCJa2J3NXb9EMEnPGmdfY2GgS7Bx6YWmKwA7D0OecYPlYtL-mw_lbfL0q2ngrXUNYxVbK1BHFkORXi79SprF9LDKOLsqXBEjByUck_pvgN-tbnRPa9M7zkvFO0A_CObnOwjlVO-yS8w-ERPbmnjxJyvkEyrI9lOCpzGYB3O4VuVeVTxd7cXhWPJaSrh6PA6dLxEYYq5Wf5R9iKLa7h805Nu5RBSnPGz1gORb-dPX-iZa9G64PoezBCllRK62jIW7OYD6MswRwZeQ_Lrx6U8RmNCRQGZq_cf96EU57zm__JzBoVPsOt24oXXETboCj-eu9OsNrN_zqKP0VDgbRzMEacqPR8_7_8DSQVAMpy-1XZ6CytpCMOa7t0fQJZxDz/http%3A%2F%2Fwww.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,248,488 as at 1 January 2018. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ***
Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
ITYM any shop that allows general user access to the RACF DB deserves to be cracked. There's nothing magic about IEBGENER. Access to sensitive information should be limited to those who need it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jones, Phil <02379a6d81f2-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, June 5, 2019 9:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL] At the risk of being controversial, I think that any z/OS site that allows general utility access to the RACF DB almost DESERVES to be hacked... Regards; Phil J. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, 6 June 2019 2:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: > Sory to inform you: there are such SVCs available for download. I > think there is one on the cbttape . While such code is available for download it is not available for install. Otherwise we talk about mistakes in configurations => human problem, not platform weakness. BTW: I know very dangerous tool for hacking RACFdb and passwords: IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 content directly to some hack site and voila. -- 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,http://secure-web.cisco.com/155_aQOAoYRplWsWRrv0Iz9uLpzX7mTLneLQ8ackg2-7lXx5ujQdijuIMoETyiMbzgjTFCJa2J3NXb9EMEnPGmdfY2GgS7Bx6YWmKwA7D0OecYPlYtL-mw_lbfL0q2ngrXUNYxVbK1BHFkORXi79SprF9LDKOLsqXBEjByUck_pvgN-tbnRPa9M7zkvFO0A_CObnOwjlVO-yS8w-ERPbmnjxJyvkEyrI9lOCpzGYB3O4VuVeVTxd7cXhWPJaSrh6PA6dLxEYYq5Wf5R9iKLa7h805Nu5RBSnPGz1gORb-dPX-iZa9G64PoezBCllRK62jIW7OYD6MswRwZeQ_Lrx6U8RmNCRQGZq_cf96EU57zm__JzBoVPsOt24oXXETboCj-eu9OsNrN_zqKP0VDgbRzMEacqPR8_7_8DSQVAMpy-1XZ6CytpCMOa7t0fQJZxDz/http%3A%2F%2Fwww.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.2018 r. wynosi 169.248.488 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,http://secure-web.cisco.com/155_aQOAoYRplWsWRrv0Iz9uLpzX7mTLneLQ8ackg2-7lXx5ujQdijuIMoETyiMbzgjTFCJa2J3NXb9EMEnPGmdfY2GgS7Bx6YWmKwA7D0OecYPlYtL-mw_lbfL0q2ngrXUNYxVbK1BHFkORXi79SprF9LDKOLsqXBEjByUck_pvgN-tbnRPa9M7zkvFO0A_CObnOwjlVO-yS8w-ERPbmnjxJyvkEyrI9lOCpzGYB3O4VuVeVTxd7cXhWPJaSrh6PA6dLxEYYq5Wf5R9iKLa7h805Nu5RBSnPGz1gORb-dPX-iZa9G64PoezBCllRK62jIW7OYD6MswRwZeQ_Lrx6U8RmNCRQGZq_cf96EU57zm__JzBoVPsOt24oXXETboCj-eu9OsNrN_zqKP0VDgbRzMEacqPR8_7_8DSQVAMpy-1XZ6CytpCMOa7t0fQJZxDz/http%3A%2F%2Fwww.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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** IMPORTANT: This e-mail is for the use of the intended recipient only and may contain information that is confidential, commercially valuable and/or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the sender immediately and delete all electronic and hard copies of this transmission to
Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
Unfortunately I have seen few. However I fixed it (that was part of my role there). And again it is not about paltform strength, it is about people. However this is the market for some companies. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-06 o 03:33, Bill Johnson pisze: Agree 100% and have never seen a shop that does. Sent from Yahoo Mail for iPhone On Wednesday, June 5, 2019, 9:29 PM, Jones, Phil <02379a6d81f2-dmarc-requ...@listserv.ua.edu> wrote: At the risk of being controversial, I think that any z/OS site that allows general utility access to the RACF DB almost DESERVES to be hacked... Regards; Phil J. == 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
So what? SVC is one of system components. Byte is set of bits. A knife can be used in the kitchen and for murder. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-05 o 19:03, ITschak Mugzach pisze: Iebgener is the ibm recommanded utility to backup racf (called by irrut200). ITschak בתאריך יום ד׳, 5 ביוני 2019, 19:41, מאת R.S. < r.skoru...@bremultibank.com.pl>: W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: Sory to inform you: there are such SVCs available for download. I think there is one on the cbttape . While such code is available for download it is not available for install. Otherwise we talk about mistakes in configurations => human problem, not platform weakness. BTW: I know very dangerous tool for hacking RACFdb and passwords: IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 content directly to some hack site and voila. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
Agree 100% and have never seen a shop that does. Sent from Yahoo Mail for iPhone On Wednesday, June 5, 2019, 9:29 PM, Jones, Phil <02379a6d81f2-dmarc-requ...@listserv.ua.edu> wrote: At the risk of being controversial, I think that any z/OS site that allows general utility access to the RACF DB almost DESERVES to be hacked... Regards; Phil J. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, 6 June 2019 2:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: > Sory to inform you: there are such SVCs available for download. I > think there is one on the cbttape . While such code is available for download it is not available for install. Otherwise we talk about mistakes in configurations => human problem, not platform weakness. BTW: I know very dangerous tool for hacking RACFdb and passwords: IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 content directly to some hack site and voila. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** IMPORTANT: This e-mail is for the use of the intended recipient only and may contain information that is confidential, commercially valuable and/or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the sender immediately and delete all electronic and hard copies of this transmission together with any attachments. Please consider the environment before printing this e-mail ** -- 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: Just how secure are mainframes? | Trevor Eddolls [SEC=UNOFFICIAL]
At the risk of being controversial, I think that any z/OS site that allows general utility access to the RACF DB almost DESERVES to be hacked... Regards; Phil J. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, 6 June 2019 2:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: > Sory to inform you: there are such SVCs available for download. I > think there is one on the cbttape . While such code is available for download it is not available for install. Otherwise we talk about mistakes in configurations => human problem, not platform weakness. BTW: I know very dangerous tool for hacking RACFdb and passwords: IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 content directly to some hack site and voila. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** IMPORTANT: This e-mail is for the use of the intended recipient only and may contain information that is confidential, commercially valuable and/or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the sender immediately and delete all electronic and hard copies of this transmission together with any attachments. Please consider the environment before printing this e-mail ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Iebgener is the ibm recommanded utility to backup racf (called by irrut200). ITschak בתאריך יום ד׳, 5 ביוני 2019, 19:41, מאת R.S. < r.skoru...@bremultibank.com.pl>: > W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: > > Sory to inform you: there are such SVCs available for download. I think > > there is one on the cbttape . > > While such code is available for download it is not available for install. > Otherwise we talk about mistakes in configurations => human problem, not > platform weakness. > > BTW: I know very dangerous tool for hacking RACFdb and passwords: > IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 > content directly to some hack site and voila. > > -- > 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. > > -- > 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: Just how secure are mainframes? | Trevor Eddolls
W dniu 2019-06-02 o 21:48, ITschak Mugzach pisze: Sory to inform you: there are such SVCs available for download. I think there is one on the cbttape . While such code is available for download it is not available for install. Otherwise we talk about mistakes in configurations => human problem, not platform weakness. BTW: I know very dangerous tool for hacking RACFdb and passwords: IEBGENER. You run IEBGENER, put RACFdb in SYSUT1, then transfer SYSUT2 content directly to some hack site and voila. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
W dniu 2019-06-03 o 05:30, ITschak Mugzach pisze: I do? You must be joking. The thread is monopolized by one person. You know who. No, it's not. Maybe Bill wrote the most, but other people also contributed significantly, including you, Ray, Lenny, me, Shmuel, Clark, Tom and others. And everyone is allowed to write more if he wants. The thread is not monopolized. I observe many emotions here which is not good since emotions go hand in hand with merit. I also observe play on sb's emotions, defy, which is even worse. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Correct Sent from Yahoo Mail for iPhone On Wednesday, June 5, 2019, 12:25 PM, R.S. wrote: W dniu 2019-06-04 o 18:52, Clark Morris pisze: > [Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >From the you can't make this up department. Mr. Marchant agrees with me. >> https://www.compuware.com/proving-z13-modern/ >> > Considering that he is writing for a mainframe systems software vendor > that provides APF authorized code, he has some interest in > perpetuating the mainframe. Also RACF is a separately priced add-on > item> Does IBM require that you license RACF or approved third party > equivalent as a condition of running z/OS? Is there a mechanism for > third party vendors that provide software that runs APF authorized to > be somehow included in the statement of integrity or have recognized > equivalents? Clark, RACF is optional feature only because there are (were) some competitive products. IBM is (has to be?) fair allowing the choice. However security server is NOT OPTIONAL for the system, you HAVE TO HAVE ONE OF THEM. Otherwise you won't be able to run many system components. So, you can choose which security server to use, not if to use it. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- 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: Just how secure are mainframes? | Trevor Eddolls
W dniu 2019-06-04 o 18:52, Clark Morris pisze: [Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >From the you can't make this up department. Mr. Marchant agrees with me. https://www.compuware.com/proving-z13-modern/ Considering that he is writing for a mainframe systems software vendor that provides APF authorized code, he has some interest in perpetuating the mainframe. Also RACF is a separately priced add-on item> Does IBM require that you license RACF or approved third party equivalent as a condition of running z/OS? Is there a mechanism for third party vendors that provide software that runs APF authorized to be somehow included in the statement of integrity or have recognized equivalents? Clark, RACF is optional feature only because there are (were) some competitive products. IBM is (has to be?) fair allowing the choice. However security server is NOT OPTIONAL for the system, you HAVE TO HAVE ONE OF THEM. Otherwise you won't be able to run many system components. So, you can choose which security server to use, not if to use it. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Regarding "you have never been hacked during 40 years". Disclaimer: this is not my case, I only analyze it from logic point of view. Indeed Bill cannot be 100% sure ha had never been hacked. Just because maybe he was hacked but the breach was not disclosed. However no one can be 100% sure of it. No one on any possible platform, maybe except single user computers not connected to any network. Can YOU prove that NOW your computer is not hacked? No. However sometimes we are "pretty sure". I'm pretty sure my mainframe is not hacked now. Do you? Last, but not least: while it would be possible to break in just for fun and do nothing, it would be more likely that bad guys break in for money. Such breach would be disclosed/know to someone. And this is the key: Bill can be sure that no KNOW breach had taken place. BTW: The above is just logic. It is not about "mainframe is secure" or "mainframe is insecure". -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-04 o 16:43, Tom Marchant pisze: On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: noise and plenty of it. PKB. You have posted more to this thread than anyone else. You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. == 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Multics... MVS and CA products 30 years ago... I strongly believe that prehistory is not good argument for discussion about contemporary systems. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-03 o 20:28, Clark Morris pisze: [Default] On 3 Jun 2019 09:41:54 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: This whole thread has consistently confused several very different issues: I agree and have questions in each of the areas. 1. How secure is z/OS itself? I recall reading that Multics was more secure than the concurrent MVS was at the time and wonder if that would have been a better base going forward. Does the design of z/OS and the tools for implementation make it more difficult to create and maintain a secure system? How secure are VM and TPF relative to z/OS? Does anyone have a feel for how secure and securable the Unisys and any other mainframe operating systems are relative to z/OS? 2. How secure is 3rd party software? 30 years ago people were complain about some of the holes in CA software. While much has changed and I assume those holes were plugged long ago, the question remains as to how we evaluate 3rd party software that by its nature has to have system hooks and run APF authorized and / or key zero (system monitors, tape management systems, etc.)? Could and should changes to z/OS be made that would allow some of this software run unauthorized and key 8? How much vulnerability do we introduce by having such things as monitors, report management systems, etc? How much security and vulnerability is at the application level where it is the application that has to determine whether access is authorized (online banking anyone)? 3. How secure is the typical shop running z/OS? Given the need to consider security at not only the operating system level but also the application level and the number of things that have to be controlled, I suspect that most organizations are less secure than they think they are. The problem starts with keeping the authorities that people have current as they change roles in an organization and leave that organization. Are the test system as secure as the production systems? Have all of the people involved including operators, people doing report distribution, application developers and maintainers etc. been properly vetted? How do we monitor to make sure people haveen't been compromised? The list goes on. Clark Morris -- 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: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
W dniu 2019-05-29 o 21:38, Savor, Thomas (Alpharetta) pisze: In securing Mainframe: One thing I've noticed over the years is how a Company will "hide" their Mainframe hardware. The Hardware for me now is in a unmarked Building that looks like a bunker (I'm told). Pretty bad that the location is in my town, however the address is NOT circulated. The first installation that I worked at, it was well known where the data center was. It was no issue to walk into Operations and tour new equipment or talk to operators. Now, forget it. The very same rules apply for any other hardware. It's not paltform specific. BTW: the address of datacenter is "gray zone". It is neither secret nor public. Youd don't publish the address in the press, you won't answer it to journalist's question. However a lot of people know this address. All vendors' CE's have to enter inside. All deliveries have to be delivered. All security folks know where they work. All of the people are not your people and in fact you have no legal method to prevent them from disclosing the information. But, again, it is completely not platform specific. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
On Tue, 4 Jun 2019 13:52:27 -0300, Clark Morris wrote: >Is there a mechanism for >third party vendors that provide software that runs APF authorized to >be somehow included in the statement of integrity or have recognized >equivalents? Other vendors are free to issue their own statements of integrity. IBM makes no statements about other vendors commitments to system integrity. The IBM statement for z/OS can be found at https://www.ibm.com/downloads/cas/OWGOKG40 It is up to customers to evaluate all of their vendors' commitments to system integrity. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Agile: doing the wrong thing quickly -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Monday, June 3, 2019 2:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls Have no idea about MultiCS, but can comment on 2 & 3 as I've seen many installations here and in EU. 1. The best way is to check the product after it was installed by the sysprog. I noticed that some of them skip installation steps. When it comes to products that depend on USS, it can be a vendor issue as well. for example, many vendors, including IBM, set wrong UMASK. almost all new products i examined, usually in a pre-prod assessment, depend on USS. 2. many organizations has a single source for distributing software, usually the system's sandbox. that mean, that you must protect the sandbox at last as production clones, because if someone can access your SMP and target libraries, a zero day (not zero, but one you haven't applied fix for yet) can be exploit in production. 3. BTW, I am seeing move to agile development, but usually there is no security expert between the team members. these people are rare... Don't buy anything from me! ITschak On Mon, Jun 3, 2019 at 9:29 PM Clark Morris wrote: > [Default] On 3 Jun 2019 09:41:54 -0700, in bit.listserv.ibm-main > sme...@gmu.edu (Seymour J Metz) wrote: > > >This whole thread has consistently confused several very different issues: > > I agree and have questions in each of the areas. > > > > 1. How secure is z/OS itself? > > I recall reading that Multics was more secure than the concurrent MVS > was at the time and wonder if that would have been a better base going > forward. Does the design of z/OS and the tools for implementation > make it more difficult to create and maintain a secure system? How > secure are VM and TPF relative to z/OS? Does anyone have a feel for > how secure and securable the Unisys and any other mainframe operating > systems are relative to z/OS? > > > > 2. How secure is 3rd party software? > > 30 years ago people were complain about some of the holes in CA > software. While much has changed and I assume those holes were > plugged long ago, the question remains as to how we evaluate 3rd party > software that by its nature has to have system hooks and run APF > authorized and / or key zero (system monitors, tape management > systems, etc.)? Could and should changes to z/OS be made that would > allow some of this software run unauthorized and key 8? How much > vulnerability do we introduce by having such things as monitors, > report management systems, etc? How much security and vulnerability > is at the application level where it is the application that has to > determine whether access is authorized (online banking anyone)? > > > > 3. How secure is the typical shop running z/OS? > > Given the need to consider security at not only the operating system > level but also the application level and the number of things that > have to be controlled, I suspect that most organizations are less > secure than they think they are. The problem starts with keeping the > authorities that people have current as they change roles in an > organization and leave that organization. Are the test system as > secure as the production systems? Have all of the people involved > including operators, people doing report distribution, application > developers and maintainers etc. been properly vetted? How do we > monitor to make sure people haveen't been compromised? The list goes > on. > > Clark Morris > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- 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: Just how secure are mainframes? | Trevor Eddolls
Bad link https://www.computerworld.com/article/2487425/target-breach-happened-because-of-a-basic-network-segmentation-error.html On Tuesday, June 4, 2019, 12:53:11 PM EDT, Clark Morris wrote: [Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >From the you can’t make this up department. Mr. Marchant agrees with me. > >https://www.compuware.com/proving-z13-modern/ > Considering that he is writing for a mainframe systems software vendor that provides APF authorized code, he has some interest in perpetuating the mainframe. Also RACF is a separately priced add-on item> Does IBM require that you license RACF or approved third party equivalent as a condition of running z/OS? Is there a mechanism for third party vendors that provide software that runs APF authorized to be somehow included in the statement of integrity or have recognized equivalents? I suspect that the data that was involved in the famous Target retailer breach was residing on a mainframe and was gotten by using credentials that were stolen from a supplier that had valid access to the data. I think the initial breach was at the supplier that was probably not running a mainframe system. Clark Morris > >Talk of “modernization” of mainframe systems is often code for redesigning >mainframe-based applications and implementing them to run on Windows, or less >frequently, on Unix or Linux. None of these systems can match the security >capabilities of modern mainframe operating systems. > > >Sent from Yahoo Mail for iPhone > > >On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant ><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: > >>noise and plenty of it. > >PKB. > >You have posted more to this thread than anyone else. > >You have claimed that security is the main reason people stay on the >mainframe, and posted a few articles that do not say what you claimed >they say. > >You have insisted several times that your MVS systems have never been >hacked without providing any evidence or serious reasoning as to how >you could know that. "40 years of experience" is not evidence. It's called >appeal to authority, and it is a logical fallacy. > >When your assertions are questioned, your response is to attack those >who question you rather than provide evidence. Another logical fallacy. -- 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: Just how secure are mainframes? | Trevor Eddolls
How target was hacked. https://www.computerworld.com/article/2487425/target-breach-happened-because-of-a-basic-network-segmentation-error.html Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 12:52 PM, Clark Morris wrote: [Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >From the you can’t make this up department. Mr. Marchant agrees with me. > >https://www.compuware.com/proving-z13-modern/ > Considering that he is writing for a mainframe systems software vendor that provides APF authorized code, he has some interest in perpetuating the mainframe. Also RACF is a separately priced add-on item> Does IBM require that you license RACF or approved third party equivalent as a condition of running z/OS? Is there a mechanism for third party vendors that provide software that runs APF authorized to be somehow included in the statement of integrity or have recognized equivalents? I suspect that the data that was involved in the famous Target retailer breach was residing on a mainframe and was gotten by using credentials that were stolen from a supplier that had valid access to the data. I think the initial breach was at the supplier that was probably not running a mainframe system. Clark Morris > >Talk of “modernization” of mainframe systems is often code for redesigning >mainframe-based applications and implementing them to run on Windows, or less >frequently, on Unix or Linux. None of these systems can match the security >capabilities of modern mainframe operating systems. > > >Sent from Yahoo Mail for iPhone > > >On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant ><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: > >>noise and plenty of it. > >PKB. > >You have posted more to this thread than anyone else. > >You have claimed that security is the main reason people stay on the >mainframe, and posted a few articles that do not say what you claimed >they say. > >You have insisted several times that your MVS systems have never been >hacked without providing any evidence or serious reasoning as to how >you could know that. "40 years of experience" is not evidence. It's called >appeal to authority, and it is a logical fallacy. > >When your assertions are questioned, your response is to attack those >who question you rather than provide evidence. Another logical fallacy. -- 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: Just how secure are mainframes? | Trevor Eddolls
Well, the vendor could submit z/OS with their software installed for a security certification, but as I understand it that's very expensive and time consuming. As for an ESM, there are a lot of facilities that won't work at all without one. BTW, just because an application isn't APF authorized and therefore doesn't have an integrity vulnerability doesn't mean that it doesn't have a security vulnerability. If it has multiple users and allows one user unauthorized access to the data of another, ... -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Tuesday, June 4, 2019 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >From the you can’t make this up department. Mr. Marchant agrees with me. > >https://secure-web.cisco.com/1-whmwv7ULNYR1Hukwy-H5Q9Q_4xxNp8kYaDWfQ_GoMFseGBxwIbMwKs0Rrl3jVK6OBpw-WYyZ1DTl6RV2xyK9yJCovsG-dNbqIg9MfqXdV2KiPKR3uYau79LHXCF-Nlgif0qWny0y-5PPH78itFajSf0D4z9XPR_j98gYPV7f54LfqOplIiFdoIWHcjisX6FjYJwbr5vx-cQqOuqZ2mLaAMEvPvINJsmmpb8y3aO-5oTSLdgkJ1FTPeky66f4xtwpBr_sAsFYPYJWf-zdA0rKGzFmfub4Uk8u2tQ5hCnKwcwe-nd4194giBemlc5fxp9ZhDMwUeUYBPRVnYX-wEFF2aQ-FiHbP_uDuQbwAs-3kOE1PadBdfq_GC3vPqUVOhSzB4jLwb7bkAAdmDVs7hRAqJYH6HZqI5F1zVEdsss6CNcwwI1PYaI3qkTyxmEqOXjNU6W9fckIIXxrEHy2expkw/https%3A%2F%2Fwww.compuware.com%2Fproving-z13-modern%2F > Considering that he is writing for a mainframe systems software vendor that provides APF authorized code, he has some interest in perpetuating the mainframe. Also RACF is a separately priced add-on item> Does IBM require that you license RACF or approved third party equivalent as a condition of running z/OS? Is there a mechanism for third party vendors that provide software that runs APF authorized to be somehow included in the statement of integrity or have recognized equivalents? I suspect that the data that was involved in the famous Target retailer breach was residing on a mainframe and was gotten by using credentials that were stolen from a supplier that had valid access to the data. I think the initial breach was at the supplier that was probably not running a mainframe system. Clark Morris > >Talk of “modernization” of mainframe systems is often code for redesigning >mainframe-based applications and implementing them to run on Windows, or less >frequently, on Unix or Linux. None of these systems can match the security >capabilities of modern mainframe operating systems. > > >Sent from Yahoo Mail for iPhone > > >On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant ><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: > >>noise and plenty of it. > >PKB. > >You have posted more to this thread than anyone else. > >You have claimed that security is the main reason people stay on the >mainframe, and posted a few articles that do not say what you claimed >they say. > >You have insisted several times that your MVS systems have never been >hacked without providing any evidence or serious reasoning as to how >you could know that. "40 years of experience" is not evidence. It's called >appeal to authority, and it is a logical fallacy. > >When your assertions are questioned, your response is to attack those >who question you rather than provide evidence. Another logical fallacy. -- 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: Just how secure are mainframes? | Trevor Eddolls
Not according to Target or any write ups I’ve read on it. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 12:52 PM, Clark Morris wrote: [Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >From the you can’t make this up department. Mr. Marchant agrees with me. > >https://www.compuware.com/proving-z13-modern/ > Considering that he is writing for a mainframe systems software vendor that provides APF authorized code, he has some interest in perpetuating the mainframe. Also RACF is a separately priced add-on item> Does IBM require that you license RACF or approved third party equivalent as a condition of running z/OS? Is there a mechanism for third party vendors that provide software that runs APF authorized to be somehow included in the statement of integrity or have recognized equivalents? I suspect that the data that was involved in the famous Target retailer breach was residing on a mainframe and was gotten by using credentials that were stolen from a supplier that had valid access to the data. I think the initial breach was at the supplier that was probably not running a mainframe system. Clark Morris > >Talk of “modernization” of mainframe systems is often code for redesigning >mainframe-based applications and implementing them to run on Windows, or less >frequently, on Unix or Linux. None of these systems can match the security >capabilities of modern mainframe operating systems. > > >Sent from Yahoo Mail for iPhone > > >On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant ><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: > >>noise and plenty of it. > >PKB. > >You have posted more to this thread than anyone else. > >You have claimed that security is the main reason people stay on the >mainframe, and posted a few articles that do not say what you claimed >they say. > >You have insisted several times that your MVS systems have never been >hacked without providing any evidence or serious reasoning as to how >you could know that. "40 years of experience" is not evidence. It's called >appeal to authority, and it is a logical fallacy. > >When your assertions are questioned, your response is to attack those >who question you rather than provide evidence. Another logical fallacy. -- 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: Just how secure are mainframes? | Trevor Eddolls
RACF comes with the OS. You turn it on and pay for it ONLY if you don’t have ACF2 or TSS. And RACF has approx 80% market share. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 12:52 PM, Clark Morris wrote: [Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >From the you can’t make this up department. Mr. Marchant agrees with me. > >https://www.compuware.com/proving-z13-modern/ > Considering that he is writing for a mainframe systems software vendor that provides APF authorized code, he has some interest in perpetuating the mainframe. Also RACF is a separately priced add-on item> Does IBM require that you license RACF or approved third party equivalent as a condition of running z/OS? Is there a mechanism for third party vendors that provide software that runs APF authorized to be somehow included in the statement of integrity or have recognized equivalents? I suspect that the data that was involved in the famous Target retailer breach was residing on a mainframe and was gotten by using credentials that were stolen from a supplier that had valid access to the data. I think the initial breach was at the supplier that was probably not running a mainframe system. Clark Morris > >Talk of “modernization” of mainframe systems is often code for redesigning >mainframe-based applications and implementing them to run on Windows, or less >frequently, on Unix or Linux. None of these systems can match the security >capabilities of modern mainframe operating systems. > > >Sent from Yahoo Mail for iPhone > > >On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant ><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: > >>noise and plenty of it. > >PKB. > >You have posted more to this thread than anyone else. > >You have claimed that security is the main reason people stay on the >mainframe, and posted a few articles that do not say what you claimed >they say. > >You have insisted several times that your MVS systems have never been >hacked without providing any evidence or serious reasoning as to how >you could know that. "40 years of experience" is not evidence. It's called >appeal to authority, and it is a logical fallacy. > >When your assertions are questioned, your response is to attack those >who question you rather than provide evidence. Another logical fallacy. -- 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: Just how secure are mainframes? | Trevor Eddolls
[Default] On 4 Jun 2019 08:56:03 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >From the you cant make this up department. Mr. Marchant agrees with me. > >https://www.compuware.com/proving-z13-modern/ > Considering that he is writing for a mainframe systems software vendor that provides APF authorized code, he has some interest in perpetuating the mainframe. Also RACF is a separately priced add-on item> Does IBM require that you license RACF or approved third party equivalent as a condition of running z/OS? Is there a mechanism for third party vendors that provide software that runs APF authorized to be somehow included in the statement of integrity or have recognized equivalents? I suspect that the data that was involved in the famous Target retailer breach was residing on a mainframe and was gotten by using credentials that were stolen from a supplier that had valid access to the data. I think the initial breach was at the supplier that was probably not running a mainframe system. Clark Morris > >Talk of modernization of mainframe systems is often code for redesigning >mainframe-based applications and implementing them to run on Windows, or less >frequently, on Unix or Linux. None of these systems can match the security >capabilities of modern mainframe operating systems. > > >Sent from Yahoo Mail for iPhone > > >On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant ><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: > >>noise and plenty of it. > >PKB. > >You have posted more to this thread than anyone else. > >You have claimed that security is the main reason people stay on the >mainframe, and posted a few articles that do not say what you claimed >they say. > >You have insisted several times that your MVS systems have never been >hacked without providing any evidence or serious reasoning as to how >you could know that. "40 years of experience" is not evidence. It's called >appeal to authority, and it is a logical fallacy. > >When your assertions are questioned, your response is to attack those >who question you rather than provide evidence. Another logical fallacy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Sounds like a combination of improper RACF configuration and vulnerabilities in various Unix components, both standard (FTP) and IBM (WebSphere). What's really disturbing is the total lack of cooperation from LE for nearly two weeks. This sounds like a case where pen testing might have saved their bacon. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Monday, June 3, 2019 4:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls How was a mainframe breach detected? A TSOID trying to access a ton of files they didn't have access too. (link to Share PDF 'how hackers breached a government (and a bank)' by Soldier of Fortran below.) https://secure-web.cisco.com/1diIq2WmycO9mehmrGwTzmCLbt_KnBvFyhZUCpwxPn1IJCNukCY1aIACm935ADVtNgQ9BnGX9-_ZdmbGpOW-TcEPkRJhzeWPGoSbE6hh0eyPTYszGh-l5PACE5jfh3KLIEM92oz5MCfblU9gLwz9KOrNzu4rB-BJiZOp1XgXRTyOp44a8f0Gw62Ko_399a6NHmu18r7MWMYFDYHTNIplgVtjRSyXA5P_actNC5qVVYdcyYw884CcRvKP2nm-uGgtNoh1YrZLN-0JFynfHDxhITKkKkxUu2KHzqoudEoI_Gh2277euHi3tQuHRVTaQDAppTa7sG9znc8p-gzGCtyFV8IdblA9wVXYVA7b-jG_EC8JUULO5R9q_IpGiE44_F95v8pJTpOBXDv-ZXkmlUMNgFV31lPRBO2M94sqX5PlH5svWBkyD-Ai0BeCBaNk5gys7/https%3A%2F%2Fwww.google.com%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3D%26esrc%3Ds%26source%3Dweb%26cd%3D1%26cad%3Drja%26uact%3D8%26ved%3D2ahUKEwj9qtK9kc7iAhUN-6wKHaMpAewQFjAAegQIABAC%26url%3Dhttps%253A%252F%252Fshare.confex.com%252Fshare%252F124%252Fwebprogram%252FHandout%252FSession16982%252FHow%252520Hackers%252520Breached%252520a%252520Government%252520%28and%252520a%252520Bank%29.pdf%26usg%3DAOvVaw1lvSNyZEIct1DU7WLqm4hY On Mon, Jun 3, 2019 at 4:42 PM Seymour J Metz wrote: > > This whole thread has consistently confused several very different issues: > > 1. How secure is z/OS itself? > > 2. How secure is 3rd party software? > > 3. How secure is the typical shop running z/OS? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Clark Morris > Sent: Sunday, June 2, 2019 9:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s trying to sell his company’s security services. Something I thought was > >not allowed on this list. > > > Whether or not he is selling something and I don't read his posts that > way, he is making some valid points. As a retired MVS (I was back in > applications by the time z/OS was available) systems programmer, I am > far more skeptical about the invulnerability of z/OS. It is too easy > to have decades old stuff still in a system in part because people > don't know why it is there or are unaware of its existence. How much > effort is required for an installation to achieve even 95 percent of > the invulnerability that is theoretically possible and keep that up. > How many holes are left in the average shop because people don't > understand the implications of all of both IBM and vendor defaults > where I will almost guarantee that there are at some defaults that > leave a system open to hacking. I think that it is difficult to > understand all of the implications of an action. Many shops may be > running exits or other systems modifications that have worked for > decades and because they work, no one has checked them to see if they > have an unintended vulnerability. I hope that none of my code that is > on file 432 of the CBT Tape (Philips light mods) has any vulnerability > but the thing that scares me is that I might not be smart enough to > find it even if I was looking for it. Good security isn't cheap. Z/OS > may be the most secure starting base but it requires real effort to > actually implement it with both good security and good usability. How > much vulnerability is there in the test systems? How much are the > systems programmer sandboxes exposed to the outside world? What > uncertainties exist in systems vendor code? Are organizations willing > or able to periodically test their systems' vulnerabilities? Can be > secure does not mean is secure? > > Clark Morris > > > >Sent from Yahoo Mail for iPhone > > > > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > > > >> * As part of a APF authorized product there is a SVC or PC routine > >>that when called will turn on the JSBCAUTH bit > > > >Ouch! > > > >If it's APF authorized then why does it need to do that? And why would you > >allow such a vendor in the door? > > &
Re: Just how secure are mainframes? | Trevor Eddolls
Well, it's important to replace all of that COBOL code using a language like C that came out this decade. Oh, wait, it didn't. But didn't Multics have B1 before MVS did? Reading the transcript I would have to assume that either the government is in the process of upgrading its 360/65 fleet to ES/9000 or that the author is inventing hisfacts out of the whole cloth. Tom was too kind. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, June 4, 2019 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls >From the you can’t make this up department. Mr. Marchant agrees with me. https://secure-web.cisco.com/1yL63m40iBCeQbG1WvmNZsrKa4FxGrXYc1ASKMXpNVzdwtqEkgBeRY3ZdRhqcYpE8x1EGH2oYCOAOaZ2bO_7UCfP3tVCijeenqLOIOeq4mRO5gAjMFyrW655_OndDRRXv6odsUjGx8U63qP3bZTyag1OE4FZs-eJeOB23r82elSblLxXJiu2Fh_IHTw21XRKd28yHEMzSPfBuKtUVSiyFfuGeaGjvjHHoXDdIpUQDoKoNszOoMM3Ar533ngeRAZ6trUZxEHPPYiskU5HZF_GQqM-hEUDOJDMBGXFyLw3zKUGwb_hECp5TXhm7GT2n576H_0c98_THsaujOvUko7S4PpkfbD9ZkQaxNo4pf6l9gFUTkzD-Mx19UmKzIMfs0HAbM4gr_mr1K2Ay7i-N7A-BtF1h8JktxkkDKEIiQ4yaS7ooLyoQlRDwtipt90OA9DNHxHsFGI0ASBqXUhnRS_pB1g/https%3A%2F%2Fwww.compuware.com%2Fproving-z13-modern%2F Talk of “modernization” of mainframe systems is often code for redesigning mainframe-based applications and implementing them to run on Windows, or less frequently, on Unix or Linux. None of these systems can match the security capabilities of modern mainframe operating systems. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: >noise and plenty of it. PKB. You have posted more to this thread than anyone else. You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. -- Tom Marchant -- 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: Just how secure are mainframes? | Trevor Eddolls
I agree. I’m out. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 11:50 AM, Carmen Vitullo wrote: where are the forum monitors when you need them, I have nothing positive or negative to add the this run out thread, ok - NO ONE is 100% secure, is the IBM-MAIN or FACEBOOK - lets move this on PLEASE ! Carmen Vitullo - Original Message - From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, June 4, 2019 10:45:31 AM Subject: Re: Just how secure are mainframes? | Trevor Eddolls You have posted more to this thread than anyone else. False You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. False, they all stated flatly security was a top 3 reason for staying on the platform. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. Proving something that did not happen is simply impossible. YOU prove it did since you claim it has. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. I have been attacked numerous times. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: >noise and plenty of it. PKB. You have posted more to this thread than anyone else. You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. -- Tom Marchant -- 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: Just how secure are mainframes? | Trevor Eddolls
>From the you can’t make this up department. Mr. Marchant agrees with me. https://www.compuware.com/proving-z13-modern/ Talk of “modernization” of mainframe systems is often code for redesigning mainframe-based applications and implementing them to run on Windows, or less frequently, on Unix or Linux. None of these systems can match the security capabilities of modern mainframe operating systems. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: >noise and plenty of it. PKB. You have posted more to this thread than anyone else. You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. -- Tom Marchant -- 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: Just how secure are mainframes? | Trevor Eddolls
where are the forum monitors when you need them, I have nothing positive or negative to add the this run out thread, ok - NO ONE is 100% secure, is the IBM-MAIN or FACEBOOK - lets move this on PLEASE ! Carmen Vitullo - Original Message - From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, June 4, 2019 10:45:31 AM Subject: Re: Just how secure are mainframes? | Trevor Eddolls You have posted more to this thread than anyone else. False You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. False, they all stated flatly security was a top 3 reason for staying on the platform. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. Proving something that did not happen is simply impossible. YOU prove it did since you claim it has. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. I have been attacked numerous times. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: >noise and plenty of it. PKB. You have posted more to this thread than anyone else. You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. -- Tom Marchant -- 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: Just how secure are mainframes? | Trevor Eddolls
You have posted more to this thread than anyone else. False You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. False, they all stated flatly security was a top 3 reason for staying on the platform. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. Proving something that did not happen is simply impossible. YOU prove it did since you claim it has. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. I have been attacked numerous times. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 10:45 AM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: >noise and plenty of it. PKB. You have posted more to this thread than anyone else. You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. -- Tom Marchant -- 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: Just how secure are mainframes? | Trevor Eddolls
On Tue, 4 Jun 2019 00:01:01 +, Bill Johnson wrote: >noise and plenty of it. PKB. You have posted more to this thread than anyone else. You have claimed that security is the main reason people stay on the mainframe, and posted a few articles that do not say what you claimed they say. You have insisted several times that your MVS systems have never been hacked without providing any evidence or serious reasoning as to how you could know that. "40 years of experience" is not evidence. It's called appeal to authority, and it is a logical fallacy. When your assertions are questioned, your response is to attack those who question you rather than provide evidence. Another logical fallacy. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Why do you people keep saying I said it was 100% secure? I never said that, ever. Nothing is 100% secure. I’m well aware of sec/int APARS and well aware of the rest. All I said was the MF is the most secure platform on the planet (by design) and security is one of the main reasons banks, insurers, and large retailers stay on it. And, I provided 3-4 articles saying exactly that. Plus, I’ve worked at a bank and multiple insurers and know that’s the case. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 9:53 AM, Rob Scott wrote: Bill Do you believe : (o) That there have never been any "magic" or "auth on" SVCs or PC routines? (o) That there is no such thing as a Sec/Int APAR? (o) That Karl Schmitz has just been wasting his breath for the last 20 years? (o) That IBM's Secure Engineering department just sit around eating doughnuts and drinking coffee? (o) User key common storage never existed? (o) That every ISV developer is as good as the very best IBM Poughkeepsie z/OS developer you can find? (o) That in-house sysprogs who tinker with their own or public domain authorized code are as good as the very best IBM Poughkeepsie z/OS developer you can find? (o) That pentest software has never found an exposure at a large mainframe site - including financial institutions? z/OS is a extremely robust and well-engineered operating system, but to claim it to be 100% secure in all deployments would be naive. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Tuesday, June 4, 2019 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls It’s a little more than coincidence that 3 of the most vociferous posters who claim the mainframe is not secure, all sell mainframe security services. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:59 AM, ITschak Mugzach wrote: Lennie, You are inviting 'he tries to sell his product / services' ... ITschak On Tue, Jun 4, 2019 at 3:45 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Bill, > > It is very difficult to prove the negative. Hence, your claim that > your system has never been hacked is difficult to prove. I think it is > possible that your system has been "hacked" and your data has been > exfiltrated. > There is no reason for the hacker to call attention to that fact that > you have been hacked. > > However, by maintaining that you have not been hacked, and also > maintaining that it is very unlikely that you would ever be hacked, I > fear you are doing your employers a disservice. > > Actually, I work through RSM partners as an independent contractor. > Yes, they sell security services. Yes, I am sometimes called upon to > deliver such services. Nothing to hide here. Most people have to work for a > living. > I imagine you do too. Just because one works in an industry does not > mean one's opinion of the industry is invalid; in fact, the opposite > is frequently true. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: > https://nam01.safelinks.protection.outlook.com/?url=www.rsmpartners.co > mdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Cccae2809339a4bc9de9 > 008d6e8ede103%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C63695250572 > 5186342sdata=79Mc6duyUK9psstxyH%2FfJq%2BVaSed9R17yT4fGdCK8oE%3D > mp;reserved=0 ‘Dance like no one is watching. Encrypt like everyone > is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 12:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > How do you demonstrate something that hasn’t happened? LOL I see your > company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: > https://nam01.safelinks.protection.outlook.com/?url=www.rsmpartners.co > mdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Cccae2809339a4bc9de9 > 008d6e8ede103%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C63695250572 > 5186342sdata=79Mc6duyUK9psstxyH%2FfJq%2BVaSed9R17yT4fGdCK8oE%3D > mp;reserved=0 ‘Dance like no one is watching. Encrypt like everyone > is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > 40 years on numerous mainframes at more than a dozen companies an
Re: Just how secure are mainframes? | Trevor Eddolls
Bill Do you believe : (o) That there have never been any "magic" or "auth on" SVCs or PC routines? (o) That there is no such thing as a Sec/Int APAR? (o) That Karl Schmitz has just been wasting his breath for the last 20 years? (o) That IBM's Secure Engineering department just sit around eating doughnuts and drinking coffee? (o) User key common storage never existed? (o) That every ISV developer is as good as the very best IBM Poughkeepsie z/OS developer you can find? (o) That in-house sysprogs who tinker with their own or public domain authorized code are as good as the very best IBM Poughkeepsie z/OS developer you can find? (o) That pentest software has never found an exposure at a large mainframe site - including financial institutions? z/OS is a extremely robust and well-engineered operating system, but to claim it to be 100% secure in all deployments would be naive. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Tuesday, June 4, 2019 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls It’s a little more than coincidence that 3 of the most vociferous posters who claim the mainframe is not secure, all sell mainframe security services. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:59 AM, ITschak Mugzach wrote: Lennie, You are inviting 'he tries to sell his product / services' ... ITschak On Tue, Jun 4, 2019 at 3:45 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Bill, > > It is very difficult to prove the negative. Hence, your claim that > your system has never been hacked is difficult to prove. I think it is > possible that your system has been "hacked" and your data has been > exfiltrated. > There is no reason for the hacker to call attention to that fact that > you have been hacked. > > However, by maintaining that you have not been hacked, and also > maintaining that it is very unlikely that you would ever be hacked, I > fear you are doing your employers a disservice. > > Actually, I work through RSM partners as an independent contractor. > Yes, they sell security services. Yes, I am sometimes called upon to > deliver such services. Nothing to hide here. Most people have to work for a > living. > I imagine you do too. Just because one works in an industry does not > mean one's opinion of the industry is invalid; in fact, the opposite > is frequently true. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: > https://nam01.safelinks.protection.outlook.com/?url=www.rsmpartners.co > mdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Cccae2809339a4bc9de9 > 008d6e8ede103%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C63695250572 > 5186342sdata=79Mc6duyUK9psstxyH%2FfJq%2BVaSed9R17yT4fGdCK8oE%3D > mp;reserved=0 ‘Dance like no one is watching. Encrypt like everyone > is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 12:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > How do you demonstrate something that hasn’t happened? LOL I see your > company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: > https://nam01.safelinks.protection.outlook.com/?url=www.rsmpartners.co > mdata=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Cccae2809339a4bc9de9 > 008d6e8ede103%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C63695250572 > 5186342sdata=79Mc6duyUK9psstxyH%2FfJq%2BVaSed9R17yT4fGdCK8oE%3D > mp;reserved=0 ‘Dance like no one is watching. Encrypt like everyone > is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > 40 years on numerous mainframes at more than a dozen companies and > we’ve never been hacked and never had any need for penetration testing. > > > Sent from Yahoo Mail for iPhone > > > On Monday, June 3, 2019, 11:54 AM, Clark Morris > wrote: > > [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s selling plain and simple. So is Mugzak. Some laboratory bs that > >he > will even show you in application code. Then no doubt analyze your > application code for a small (large) fee.
Re: Just how secure are mainframes? | Trevor Eddolls
Just maybe, they are the ones who understand the problems, as they spend time focussed on them. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 14:09 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls It’s a little more than coincidence that 3 of the most vociferous posters who claim the mainframe is not secure, all sell mainframe security services. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:59 AM, ITschak Mugzach wrote: Lennie, You are inviting 'he tries to sell his product / services' ... ITschak On Tue, Jun 4, 2019 at 3:45 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Bill, > > It is very difficult to prove the negative. Hence, your claim that > your system has never been hacked is difficult to prove. I think it is > possible that your system has been "hacked" and your data has been > exfiltrated. > There is no reason for the hacker to call attention to that fact that > you have been hacked. > > However, by maintaining that you have not been hacked, and also > maintaining that it is very unlikely that you would ever be hacked, I > fear you are doing your employers a disservice. > > Actually, I work through RSM partners as an independent contractor. > Yes, they sell security services. Yes, I am sometimes called upon to > deliver such services. Nothing to hide here. Most people have to work for a > living. > I imagine you do too. Just because one works in an industry does not > mean one's opinion of the industry is invalid; in fact, the opposite > is frequently true. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 12:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > How do you demonstrate something that hasn’t happened? LOL I see your > company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > 40 years on numerous mainframes at more than a dozen companies and > we’ve never been hacked and never had any need for penetration testing. > > > Sent from Yahoo Mail for iPhone > > > On Monday, June 3, 2019, 11:54 AM, Clark Morris > wrote: > > [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s selling plain and simple. So is Mugzak. Some laboratory bs that > >he > will even show you in application code. Then no doubt analyze your > application code for a small (large) fee. Nobody is saying the > mainframe is fool proof. But, it is inherently (by design) more secure > than any other platform. And, a major reason why almost every bank, > insurance company, and major retailers still have them. > >Sent from Yahoo Mail for iPhone > > > As a retired systems programmer whose only computer related > investments are Microsoft, IBM and HPE my belief is that if your > organization's computer system is connected to the Internet (including > from PC's using > TN3270 emulation), your organization is subject to attack. If it does > not have a group or outside organization such as IBM, Trevor's > organization or ITschak's organization doing periodic ongoing > penetration testing, your organization won't know what vulnerabilities > exist. Since I don't know enough about the Unisys mainframes to > comment on how well they can be secured, I can't comment on how secure > they can be made but I do know it is a major effort to take advantage > of all the tools on any system in making it secure and keeping it that > way. If I knew of any major mainframe user that does not continually > check their systems for vulnerabilities, I would be tempted to short > sell their stock because they probably either have been breached or will be > in the near future. > > Clark Morris > > > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris > wrote: > > > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >
Re: Just how secure are mainframes? | Trevor Eddolls
It’s a little more than coincidence that 3 of the most vociferous posters who claim the mainframe is not secure, all sell mainframe security services. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:59 AM, ITschak Mugzach wrote: Lennie, You are inviting 'he tries to sell his product / services' ... ITschak On Tue, Jun 4, 2019 at 3:45 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Bill, > > It is very difficult to prove the negative. Hence, your claim that your > system has never been hacked is difficult to prove. I think it is possible > that your system has been "hacked" and your data has been exfiltrated. > There is no reason for the hacker to call attention to that fact that you > have been hacked. > > However, by maintaining that you have not been hacked, and also > maintaining that it is very unlikely that you would ever be hacked, I fear > you are doing your employers a disservice. > > Actually, I work through RSM partners as an independent contractor. Yes, > they sell security services. Yes, I am sometimes called upon to deliver > such services. Nothing to hide here. Most people have to work for a living. > I imagine you do too. Just because one works in an industry does not mean > one's opinion of the industry is invalid; in fact, the opposite is > frequently true. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Bill Johnson > Sent: 04 June 2019 12:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls > > How do you demonstrate something that hasn’t happened? LOL I see your > company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls > > 40 years on numerous mainframes at more than a dozen companies and we’ve > never been hacked and never had any need for penetration testing. > > > Sent from Yahoo Mail for iPhone > > > On Monday, June 3, 2019, 11:54 AM, Clark Morris > wrote: > > [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he > will even show you in application code. Then no doubt analyze your > application code for a small (large) fee. Nobody is saying the mainframe is > fool proof. But, it is inherently (by design) more secure than any other > platform. And, a major reason why almost every bank, insurance company, and > major retailers still have them. > >Sent from Yahoo Mail for iPhone > > > As a retired systems programmer whose only computer related investments > are Microsoft, IBM and HPE my belief is that if your organization's > computer system is connected to the Internet (including from PC's using > TN3270 emulation), your organization is subject to attack. If it does not > have a group or outside organization such as IBM, Trevor's organization or > ITschak's organization doing periodic ongoing penetration testing, your > organization won't know what vulnerabilities exist. Since I don't know > enough about the Unisys mainframes to comment on how well they can be > secured, I can't comment on how secure they can be made but I do know it is > a major effort to take advantage of all the tools on any system in making > it secure and keeping it that way. If I knew of any major mainframe user > that does not continually check their systems for vulnerabilities, I would > be tempted to short sell their stock because they probably either have been > breached or will be in the near future. > > Clark Morris > > > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris > wrote: > > > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main > >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > > >>He’s trying to sell his company’s security services. Something I thought > was not allowed on this list. > >> > >Whether or not he is selling something and I don't read his posts that > >way, he is making some valid points. As a retired MVS (I was back in > >applications by the time z/OS was available) systems programmer, I am > >far more skeptical about the invulnerability of z/OS. It is too easy > >to have decades old stuff still in a system in part because people >
Re: Just how secure are mainframes? | Trevor Eddolls
Bill, So you have not seen these things. Others have. Please accept their word for this. If you were as rich as Warren Buffet then you could afford to employ others to work out if you need a haircut. Maybe you could teach yourself those skills. Your logic takes us down a path of only taking advice from those who have no experience. Your choice. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 13:52 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls In 40 years, I’ve never seen any company I’ve worked for have their mainframe hacked or compromised. Including a bank and multiple insurance companies. Plus, I was in positions to know. I have seen numerous hacks and compromises of non mainframe platforms at those companies. As Warren Buffett says: Never ask your barber if you need a haircut. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:44 AM, Lennie Dymoke-Bradshaw wrote: Bill, It is very difficult to prove the negative. Hence, your claim that your system has never been hacked is difficult to prove. I think it is possible that your system has been "hacked" and your data has been exfiltrated. There is no reason for the hacker to call attention to that fact that you have been hacked. However, by maintaining that you have not been hacked, and also maintaining that it is very unlikely that you would ever be hacked, I fear you are doing your employers a disservice. Actually, I work through RSM partners as an independent contractor. Yes, they sell security services. Yes, I am sometimes called upon to deliver such services. Nothing to hide here. Most people have to work for a living. I imagine you do too. Just because one works in an industry does not mean one's opinion of the industry is invalid; in fact, the opposite is frequently true. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 12:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls How do you demonstrate something that hasn’t happened? LOL I see your company sells security services too. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw wrote: How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On
Re: Just how secure are mainframes? | Trevor Eddolls
Lennie, You are inviting 'he tries to sell his product / services' ... ITschak On Tue, Jun 4, 2019 at 3:45 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Bill, > > It is very difficult to prove the negative. Hence, your claim that your > system has never been hacked is difficult to prove. I think it is possible > that your system has been "hacked" and your data has been exfiltrated. > There is no reason for the hacker to call attention to that fact that you > have been hacked. > > However, by maintaining that you have not been hacked, and also > maintaining that it is very unlikely that you would ever be hacked, I fear > you are doing your employers a disservice. > > Actually, I work through RSM partners as an independent contractor. Yes, > they sell security services. Yes, I am sometimes called upon to deliver > such services. Nothing to hide here. Most people have to work for a living. > I imagine you do too. Just because one works in an industry does not mean > one's opinion of the industry is invalid; in fact, the opposite is > frequently true. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Bill Johnson > Sent: 04 June 2019 12:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls > > How do you demonstrate something that hasn’t happened? LOL I see your > company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls > > 40 years on numerous mainframes at more than a dozen companies and we’ve > never been hacked and never had any need for penetration testing. > > > Sent from Yahoo Mail for iPhone > > > On Monday, June 3, 2019, 11:54 AM, Clark Morris > wrote: > > [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he > will even show you in application code. Then no doubt analyze your > application code for a small (large) fee. Nobody is saying the mainframe is > fool proof. But, it is inherently (by design) more secure than any other > platform. And, a major reason why almost every bank, insurance company, and > major retailers still have them. > >Sent from Yahoo Mail for iPhone > > > As a retired systems programmer whose only computer related investments > are Microsoft, IBM and HPE my belief is that if your organization's > computer system is connected to the Internet (including from PC's using > TN3270 emulation), your organization is subject to attack. If it does not > have a group or outside organization such as IBM, Trevor's organization or > ITschak's organization doing periodic ongoing penetration testing, your > organization won't know what vulnerabilities exist. Since I don't know > enough about the Unisys mainframes to comment on how well they can be > secured, I can't comment on how secure they can be made but I do know it is > a major effort to take advantage of all the tools on any system in making > it secure and keeping it that way. If I knew of any major mainframe user > that does not continually check their systems for vulnerabilities, I would > be tempted to short sell their stock because they probably either have been > breached or will be in the near future. > > Clark Morris > > > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris > wrote: > > > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main > >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > > >>He’s trying to sell his company’s security services. Something I thought > was not allowed on this list. > >> > >Whether or not he is selling something and I don't read his posts that > >way, he is making some valid points. As a retired MVS (I was back in > >applications by the time z/OS was available) systems programmer, I am > >far more skeptical about the invulnerability of z/OS. It is too easy > >to have decades old stuff still in a system in part because people > >don't know why it is there or are unaware of its existence. How much > >effort is required for an installation to achieve even 95 percent of > >the invulnerability that is theoretically possible and keep that up. > >How many holes are left in the
Re: Just how secure are mainframes? | Trevor Eddolls
In 40 years, I’ve never seen any company I’ve worked for have their mainframe hacked or compromised. Including a bank and multiple insurance companies. Plus, I was in positions to know. I have seen numerous hacks and compromises of non mainframe platforms at those companies. As Warren Buffett says: Never ask your barber if you need a haircut. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:44 AM, Lennie Dymoke-Bradshaw wrote: Bill, It is very difficult to prove the negative. Hence, your claim that your system has never been hacked is difficult to prove. I think it is possible that your system has been "hacked" and your data has been exfiltrated. There is no reason for the hacker to call attention to that fact that you have been hacked. However, by maintaining that you have not been hacked, and also maintaining that it is very unlikely that you would ever be hacked, I fear you are doing your employers a disservice. Actually, I work through RSM partners as an independent contractor. Yes, they sell security services. Yes, I am sometimes called upon to deliver such services. Nothing to hide here. Most people have to work for a living. I imagine you do too. Just because one works in an industry does not mean one's opinion of the industry is invalid; in fact, the opposite is frequently true. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 12:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls How do you demonstrate something that hasn’t happened? LOL I see your company sells security services too. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw wrote: How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95
Re: Just how secure are mainframes? | Trevor Eddolls
Bill, It is very difficult to prove the negative. Hence, your claim that your system has never been hacked is difficult to prove. I think it is possible that your system has been "hacked" and your data has been exfiltrated. There is no reason for the hacker to call attention to that fact that you have been hacked. However, by maintaining that you have not been hacked, and also maintaining that it is very unlikely that you would ever be hacked, I fear you are doing your employers a disservice. Actually, I work through RSM partners as an independent contractor. Yes, they sell security services. Yes, I am sometimes called upon to deliver such services. Nothing to hide here. Most people have to work for a living. I imagine you do too. Just because one works in an industry does not mean one's opinion of the industry is invalid; in fact, the opposite is frequently true. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 12:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls How do you demonstrate something that hasn’t happened? LOL I see your company sells security services too. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw wrote: How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other
Re: Just how secure are mainframes? | Trevor Eddolls
Quite different. The sell the security as part of the OS. They don’t then bash the security (their own product) and try to sell you additional products. IBM actually tells you how great mainframe security is and use it as a selling point to industries where security is paramount. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 7:46 AM, Lou Losee wrote: So does IBM Lou On Tue, Jun 4, 2019 at 6:38 AM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > How do you demonstrate something that hasn’t happened? LOL > I see your company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls > > 40 years on numerous mainframes at more than a dozen companies and we’ve > never been hacked and never had any need for penetration testing. > > > Sent from Yahoo Mail for iPhone > > > On Monday, June 3, 2019, 11:54 AM, Clark Morris > wrote: > > [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he > will even show you in application code. Then no doubt analyze your > application code for a small (large) fee. Nobody is saying the mainframe is > fool proof. But, it is inherently (by design) more secure than any other > platform. And, a major reason why almost every bank, insurance company, and > major retailers still have them. > >Sent from Yahoo Mail for iPhone > > > As a retired systems programmer whose only computer related investments > are Microsoft, IBM and HPE my belief is that if your organization's > computer system is connected to the Internet (including from PC's using > TN3270 emulation), your organization is subject to attack. If it does not > have a group or outside organization such as IBM, Trevor's organization or > ITschak's organization doing periodic ongoing penetration testing, your > organization won't know what vulnerabilities exist. Since I don't know > enough about the Unisys mainframes to comment on how well they can be > secured, I can't comment on how secure they can be made but I do know it is > a major effort to take advantage of all the tools on any system in making > it secure and keeping it that way. If I knew of any major mainframe user > that does not continually check their systems for vulnerabilities, I would > be tempted to short sell their stock because they probably either have been > breached or will be in the near future. > > Clark Morris > > > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris > wrote: > > > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main > >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > > >>He’s trying to sell his company’s security services. Something I thought > was not allowed on this list. > >> > >Whether or not he is selling something and I don't read his posts that > >way, he is making some valid points. As a retired MVS (I was back in > >applications by the time z/OS was available) systems programmer, I am > >far more skeptical about the invulnerability of z/OS. It is too easy > >to have decades old stuff still in a system in part because people > >don't know why it is there or are unaware of its existence. How much > >effort is required for an installation to achieve even 95 percent of > >the invulnerability that is theoretically possible and keep that up. > >How many holes are left in the average shop because people don't > >understand the implications of all of both IBM and vendor defaults > >where I will almost guarantee that there are at some defaults that > >leave a system open to hacking. I think that it is difficult to > >understand all of the implications of an action. Many shops may be > >running exits or other systems modifications that have worked for > >decades and because they work, no one has checked them to see if they > >have an unintended vulnerability. I hope that none of my code that is > >on file 432 of the CBT Tape (Philips light mods) has any vulnerability > >but the thing that scares me is that I might not be smart enough to > >find it even if I was looking for it. Good security isn't cheap. Z/OS > >may be the most secure starting base but it requires real effort to > >actually implement it with both good security and good usability. How > >much vulnerability is there in the test systems? How much are the > >systems programmer
Re: Just how secure are mainframes? | Trevor Eddolls
So does IBM Lou On Tue, Jun 4, 2019 at 6:38 AM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > How do you demonstrate something that hasn’t happened? LOL > I see your company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls > > 40 years on numerous mainframes at more than a dozen companies and we’ve > never been hacked and never had any need for penetration testing. > > > Sent from Yahoo Mail for iPhone > > > On Monday, June 3, 2019, 11:54 AM, Clark Morris > wrote: > > [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he > will even show you in application code. Then no doubt analyze your > application code for a small (large) fee. Nobody is saying the mainframe is > fool proof. But, it is inherently (by design) more secure than any other > platform. And, a major reason why almost every bank, insurance company, and > major retailers still have them. > >Sent from Yahoo Mail for iPhone > > > As a retired systems programmer whose only computer related investments > are Microsoft, IBM and HPE my belief is that if your organization's > computer system is connected to the Internet (including from PC's using > TN3270 emulation), your organization is subject to attack. If it does not > have a group or outside organization such as IBM, Trevor's organization or > ITschak's organization doing periodic ongoing penetration testing, your > organization won't know what vulnerabilities exist. Since I don't know > enough about the Unisys mainframes to comment on how well they can be > secured, I can't comment on how secure they can be made but I do know it is > a major effort to take advantage of all the tools on any system in making > it secure and keeping it that way. If I knew of any major mainframe user > that does not continually check their systems for vulnerabilities, I would > be tempted to short sell their stock because they probably either have been > breached or will be in the near future. > > Clark Morris > > > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris > wrote: > > > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main > >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > > >>He’s trying to sell his company’s security services. Something I thought > was not allowed on this list. > >> > >Whether or not he is selling something and I don't read his posts that > >way, he is making some valid points. As a retired MVS (I was back in > >applications by the time z/OS was available) systems programmer, I am > >far more skeptical about the invulnerability of z/OS. It is too easy > >to have decades old stuff still in a system in part because people > >don't know why it is there or are unaware of its existence. How much > >effort is required for an installation to achieve even 95 percent of > >the invulnerability that is theoretically possible and keep that up. > >How many holes are left in the average shop because people don't > >understand the implications of all of both IBM and vendor defaults > >where I will almost guarantee that there are at some defaults that > >leave a system open to hacking. I think that it is difficult to > >understand all of the implications of an action. Many shops may be > >running exits or other systems modifications that have worked for > >decades and because they work, no one has checked them to see if they > >have an unintended vulnerability. I hope that none of my code that is > >on file 432 of the CBT Tape (Philips light mods) has any vulnerability > >but the thing that scares me is that I might not be smart enough to > >find it even if I was looking for it. Good security isn't cheap. Z/OS > >may be the most secure starting base but it requires real effort to > >actually implement it with both good security and good usability. How > >much vulnerability is there in the test systems? How much are the > >systems programmer sandboxes exposed to the outside world? What > >uncertainties exist in systems vendor code? Are organizations willing > >or able to periodically test their systems' vulnerabilities? Can be > >secure does not mean is secure? > > > >Clark Morris > >> > >>Sent from Yahoo Mail for iPhone > >> > >> > >>On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> > >>> * As
Re: Just how secure are mainframes? | Trevor Eddolls
How do you demonstrate something that hasn’t happened? LOL I see your company sells security services too. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw wrote: How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other systems modifications that have worked for >decades and because they work, no one has checked them to see if they >have an unintended vulnerability. I hope that none of my code that is >on file 432 of the CBT Tape (Philips light mods) has any vulnerability >but the thing that scares me is that I might not be smart enough to >find it even if I was looking for it. Good security isn't cheap. Z/OS >may be the most secure starting base but it requires real effort to >actually implement it with both good security and good usability. How >much vulnerability is there in the test systems? How much are the >systems programmer sandboxes exposed to the outside world? What >uncertainties exist in systems vendor code? Are organizations willing >or able to periodically test their systems' vulnerabilities? Can be >secure does not mean is secure? > >Clark Morris >> >>Sent from Yahoo Mail for iPhone >> >> >>On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: >> >>> * As part of a APF authorized product there is a SVC or PC routine >>> that when called will turn on the JSBCAUTH bit >> >>Ouch! >> >>If it's APF authorized then why does it need to do that? And why would you >>allow such a vendor in the door? >> >>Did you have a tool that discovered
Re: Just how secure are mainframes? | Trevor Eddolls
How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other systems modifications that have worked for >decades and because they work, no one has checked them to see if they >have an unintended vulnerability. I hope that none of my code that is >on file 432 of the CBT Tape (Philips light mods) has any vulnerability >but the thing that scares me is that I might not be smart enough to >find it even if I was looking for it. Good security isn't cheap. Z/OS >may be the most secure starting base but it requires real effort to >actually implement it with both good security and good usability. How >much vulnerability is there in the test systems? How much are the >systems programmer sandboxes exposed to the outside world? What >uncertainties exist in systems vendor code? Are organizations willing >or able to periodically test their systems' vulnerabilities? Can be >secure does not mean is secure? > >Clark Morris >> >>Sent from Yahoo Mail for iPhone >> >> >>On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: >> >>> * As part of a APF authorized product there is a SVC or PC routine >>> that when called will turn on the JSBCAUTH bit >> >>Ouch! >> >>If it's APF authorized then why does it need to do that? And why would you >>allow such a vendor in the door? >> >>Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >>or did you have to read the code like the rest of us? > >-- >For IBM-MAIN subscribe / signoff /
Re: Just how secure are mainframes? | Trevor Eddolls
Well said! I had forgotten Cassandra's prophecy. Good analogy, Rob. :-) I wish my shop had done pen testing a few years ago. :-( -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Tuesday, June 04, 2019 5:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls >>>> "40 years on numerous mainframes at more than a dozen companies and we’ve >>>> never been hacked and never had any need for penetration testing." ...said King Priam to Cassandra -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Tuesday, June 4, 2019 1:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other systems modifications that have worked for >decades and because they work, no one has checked them to see if they >have an unintended vulnerability. I hope that none of my code that is >on file 432 of the CBT Tape (Philips light mods) has any vulnerability >but the thing that scares me is that I might not be smart enough to >find it even if I was looking for it. Good security isn't cheap. Z/OS >may be the most secure starting base but it requires real effort to >actually implement it with both good security and good usability. How >much vulnerability is there in the test systems? How much are the >systems programmer sandboxes exposed to the outside world? What >uncertainties exist in systems vendor code? Are organizations willing >or able to periodically test their systems' vulnerabilities? Can be >secure does not mean is secure? > >Clark Morris >> >>Sent from Yahoo Mail for iPhone >> >> >>On Sunday, June 2, 2019, 4:04
Re: Just how secure are mainframes? | Trevor Eddolls
>>>> "40 years on numerous mainframes at more than a dozen companies and we’ve >>>> never been hacked and never had any need for penetration testing." ...said King Priam to Cassandra -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Tuesday, June 4, 2019 1:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other systems modifications that have worked for >decades and because they work, no one has checked them to see if they >have an unintended vulnerability. I hope that none of my code that is >on file 432 of the CBT Tape (Philips light mods) has any vulnerability >but the thing that scares me is that I might not be smart enough to >find it even if I was looking for it. Good security isn't cheap. Z/OS >may be the most secure starting base but it requires real effort to >actually implement it with both good security and good usability. How >much vulnerability is there in the test systems? How much are the >systems programmer sandboxes exposed to the outside world? What >uncertainties exist in systems vendor code? Are organizations willing >or able to periodically test their systems' vulnerabilities? Can be >secure does not mean is secure? > >Clark Morris >> >>Sent from Yahoo Mail for iPhone >> >> >>On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: >> >>> * As part of a APF authorized product there is a SVC or PC routine >>>that when called will turn on the JSBCAUTH bit >> >>Ouch! >> >>If it's APF authorized then why does it need to do that? And why would you >>allow such a vendor in the door? >> >>Did you have a tool
Re: Just how secure are mainframes? | Trevor Eddolls
*PLONK* -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Monday, June 03, 2019 8:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls Lol, yeah, because the more someone posts, the smarter they are!!! I’ve got more experience than him, in all facets of the mainframe. In many industries. I couldn’t care less who you believe or trust. I don’t sell security, he does. In my experience on this site, the IBMers are the ones I pay attention to. The rest is noise and plenty of it. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 9:02 AM, Richards, Robert B. <01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: The only one selling here is you. You are selling BS and we are not buying it. Remember, according to you, we known it all. So why do you continue? I'll take Ray's intentions over yours *every single time*. He has earned it from this industry many times over. Just because he has had security products that sell over the decades does not mean he can't be a trusted source for answers relating to security, ACF2, Pen testing, etc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, June 02, 2019 10:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will even show you in application code. Then no doubt analyze your application code for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it is inherently (by design) more secure than any other platform. And, a major reason why almost every bank, insurance company, and major retailers still have them. Sent from Yahoo Mail for iPhone On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s trying to sell his company’s security services. Something I thought was >not allowed on this list. > Whether or not he is selling something and I don't read his posts that way, he is making some valid points. As a retired MVS (I was back in applications by the time z/OS was available) systems programmer, I am far more skeptical about the invulnerability of z/OS. It is too easy to have decades old stuff still in a system in part because people don't know why it is there or are unaware of its existence. How much effort is required for an installation to achieve even 95 percent of the invulnerability that is theoretically possible and keep that up. How many holes are left in the average shop because people don't understand the implications of all of both IBM and vendor defaults where I will almost guarantee that there are at some defaults that leave a system open to hacking. I think that it is difficult to understand all of the implications of an action. Many shops may be running exits or other systems modifications that have worked for decades and because they work, no one has checked them to see if they have an unintended vulnerability. I hope that none of my code that is on file 432 of the CBT Tape (Philips light mods) has any vulnerability but the thing that scares me is that I might not be smart enough to find it even if I was looking for it. Good security isn't cheap. Z/OS may be the most secure starting base but it requires real effort to actually implement it with both good security and good usability. How much vulnerability is there in the test systems? How much are the systems programmer sandboxes exposed to the outside world? What uncertainties exist in systems vendor code? Are organizations willing or able to periodically test their systems' vulnerabilities? Can be secure does not mean is secure? Clark Morris > >Sent from Yahoo Mail for iPhone > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> * As part of a APF authorized product there is a SVC or PC routine >> that when called will turn on the JSBCAUTH bit > >Ouch! > >If it's APF authorized then why does it need to do that? And why would you >allow such a vendor in the door? > >Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >or did you have to read the code like the rest of us? -- 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 I
Re: Just how secure are mainframes? | Trevor Eddolls
Seymour has it right. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 12:42 PM, Seymour J Metz wrote: This whole thread has consistently confused several very different issues: 1. How secure is z/OS itself? 2. How secure is 3rd party software? 3. How secure is the typical shop running z/OS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Sunday, June 2, 2019 9:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s trying to sell his company’s security services. Something I thought was >not allowed on this list. > Whether or not he is selling something and I don't read his posts that way, he is making some valid points. As a retired MVS (I was back in applications by the time z/OS was available) systems programmer, I am far more skeptical about the invulnerability of z/OS. It is too easy to have decades old stuff still in a system in part because people don't know why it is there or are unaware of its existence. How much effort is required for an installation to achieve even 95 percent of the invulnerability that is theoretically possible and keep that up. How many holes are left in the average shop because people don't understand the implications of all of both IBM and vendor defaults where I will almost guarantee that there are at some defaults that leave a system open to hacking. I think that it is difficult to understand all of the implications of an action. Many shops may be running exits or other systems modifications that have worked for decades and because they work, no one has checked them to see if they have an unintended vulnerability. I hope that none of my code that is on file 432 of the CBT Tape (Philips light mods) has any vulnerability but the thing that scares me is that I might not be smart enough to find it even if I was looking for it. Good security isn't cheap. Z/OS may be the most secure starting base but it requires real effort to actually implement it with both good security and good usability. How much vulnerability is there in the test systems? How much are the systems programmer sandboxes exposed to the outside world? What uncertainties exist in systems vendor code? Are organizations willing or able to periodically test their systems' vulnerabilities? Can be secure does not mean is secure? Clark Morris > >Sent from Yahoo Mail for iPhone > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> * As part of a APF authorized product there is a SVC or PC routine >> that when called will turn on the JSBCAUTH bit > >Ouch! > >If it's APF authorized then why does it need to do that? And why would you >allow such a vendor in the door? > >Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >or did you have to read the code like the rest of us? -- 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: Just how secure are mainframes? | Trevor Eddolls
40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other systems modifications that have worked for >decades and because they work, no one has checked them to see if they >have an unintended vulnerability. I hope that none of my code that is >on file 432 of the CBT Tape (Philips light mods) has any vulnerability >but the thing that scares me is that I might not be smart enough to >find it even if I was looking for it. Good security isn't cheap. Z/OS >may be the most secure starting base but it requires real effort to >actually implement it with both good security and good usability. How >much vulnerability is there in the test systems? How much are the >systems programmer sandboxes exposed to the outside world? What >uncertainties exist in systems vendor code? Are organizations willing >or able to periodically test their systems' vulnerabilities? Can be >secure does not mean is secure? > >Clark Morris >> >>Sent from Yahoo Mail for iPhone >> >> >>On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: >> >>> * As part of a APF authorized product there is a SVC or PC routine >>> that when called will turn on the JSBCAUTH bit >> >>Ouch! >> >>If it's APF authorized then why does it need to do that? And why would you >>allow such a vendor in the door? >> >>Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >>or did you have to read the code like the rest of us? > >-- >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
Re: Just how secure are mainframes? | Trevor Eddolls
Lol, yeah, because the more someone posts, the smarter they are!!! I’ve got more experience than him, in all facets of the mainframe. In many industries. I couldn’t care less who you believe or trust. I don’t sell security, he does. In my experience on this site, the IBMers are the ones I pay attention to. The rest is noise and plenty of it. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 9:02 AM, Richards, Robert B. <01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: The only one selling here is you. You are selling BS and we are not buying it. Remember, according to you, we known it all. So why do you continue? I'll take Ray's intentions over yours *every single time*. He has earned it from this industry many times over. Just because he has had security products that sell over the decades does not mean he can't be a trusted source for answers relating to security, ACF2, Pen testing, etc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, June 02, 2019 10:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will even show you in application code. Then no doubt analyze your application code for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it is inherently (by design) more secure than any other platform. And, a major reason why almost every bank, insurance company, and major retailers still have them. Sent from Yahoo Mail for iPhone On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s trying to sell his company’s security services. Something I thought was >not allowed on this list. > Whether or not he is selling something and I don't read his posts that way, he is making some valid points. As a retired MVS (I was back in applications by the time z/OS was available) systems programmer, I am far more skeptical about the invulnerability of z/OS. It is too easy to have decades old stuff still in a system in part because people don't know why it is there or are unaware of its existence. How much effort is required for an installation to achieve even 95 percent of the invulnerability that is theoretically possible and keep that up. How many holes are left in the average shop because people don't understand the implications of all of both IBM and vendor defaults where I will almost guarantee that there are at some defaults that leave a system open to hacking. I think that it is difficult to understand all of the implications of an action. Many shops may be running exits or other systems modifications that have worked for decades and because they work, no one has checked them to see if they have an unintended vulnerability. I hope that none of my code that is on file 432 of the CBT Tape (Philips light mods) has any vulnerability but the thing that scares me is that I might not be smart enough to find it even if I was looking for it. Good security isn't cheap. Z/OS may be the most secure starting base but it requires real effort to actually implement it with both good security and good usability. How much vulnerability is there in the test systems? How much are the systems programmer sandboxes exposed to the outside world? What uncertainties exist in systems vendor code? Are organizations willing or able to periodically test their systems' vulnerabilities? Can be secure does not mean is secure? Clark Morris > >Sent from Yahoo Mail for iPhone > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> * As part of a APF authorized product there is a SVC or PC routine >> that when called will turn on the JSBCAUTH bit > >Ouch! > >If it's APF authorized then why does it need to do that? And why would you >allow such a vendor in the door? > >Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >or did you have to read the code like the rest of us? -- 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 instructio
Re: Just how secure are mainframes? | Trevor Eddolls
How was a mainframe breach detected? A TSOID trying to access a ton of files they didn't have access too. (link to Share PDF 'how hackers breached a government (and a bank)' by Soldier of Fortran below.) https://www.google.com/url?sa=t=j==s=web=1=rja=8=2ahUKEwj9qtK9kc7iAhUN-6wKHaMpAewQFjAAegQIABAC=https%3A%2F%2Fshare.confex.com%2Fshare%2F124%2Fwebprogram%2FHandout%2FSession16982%2FHow%2520Hackers%2520Breached%2520a%2520Government%2520(and%2520a%2520Bank).pdf=AOvVaw1lvSNyZEIct1DU7WLqm4hY On Mon, Jun 3, 2019 at 4:42 PM Seymour J Metz wrote: > > This whole thread has consistently confused several very different issues: > > 1. How secure is z/OS itself? > > 2. How secure is 3rd party software? > > 3. How secure is the typical shop running z/OS? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Clark Morris > Sent: Sunday, June 2, 2019 9:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s trying to sell his company’s security services. Something I thought was > >not allowed on this list. > > > Whether or not he is selling something and I don't read his posts that > way, he is making some valid points. As a retired MVS (I was back in > applications by the time z/OS was available) systems programmer, I am > far more skeptical about the invulnerability of z/OS. It is too easy > to have decades old stuff still in a system in part because people > don't know why it is there or are unaware of its existence. How much > effort is required for an installation to achieve even 95 percent of > the invulnerability that is theoretically possible and keep that up. > How many holes are left in the average shop because people don't > understand the implications of all of both IBM and vendor defaults > where I will almost guarantee that there are at some defaults that > leave a system open to hacking. I think that it is difficult to > understand all of the implications of an action. Many shops may be > running exits or other systems modifications that have worked for > decades and because they work, no one has checked them to see if they > have an unintended vulnerability. I hope that none of my code that is > on file 432 of the CBT Tape (Philips light mods) has any vulnerability > but the thing that scares me is that I might not be smart enough to > find it even if I was looking for it. Good security isn't cheap. Z/OS > may be the most secure starting base but it requires real effort to > actually implement it with both good security and good usability. How > much vulnerability is there in the test systems? How much are the > systems programmer sandboxes exposed to the outside world? What > uncertainties exist in systems vendor code? Are organizations willing > or able to periodically test their systems' vulnerabilities? Can be > secure does not mean is secure? > > Clark Morris > > > >Sent from Yahoo Mail for iPhone > > > > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > > > >> * As part of a APF authorized product there is a SVC or PC routine > >>that when called will turn on the JSBCAUTH bit > > > >Ouch! > > > >If it's APF authorized then why does it need to do that? And why would you > >allow such a vendor in the door? > > > >Did you have a tool that discovered that the vendor's SVC turned on > >JSCBAUTH, or did you have to read the code like the rest of us? > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
Have no idea about MultiCS, but can comment on 2 & 3 as I've seen many installations here and in EU. 1. The best way is to check the product after it was installed by the sysprog. I noticed that some of them skip installation steps. When it comes to products that depend on USS, it can be a vendor issue as well. for example, many vendors, including IBM, set wrong UMASK. almost all new products i examined, usually in a pre-prod assessment, depend on USS. 2. many organizations has a single source for distributing software, usually the system's sandbox. that mean, that you must protect the sandbox at last as production clones, because if someone can access your SMP and target libraries, a zero day (not zero, but one you haven't applied fix for yet) can be exploit in production. 3. BTW, I am seeing move to agile development, but usually there is no security expert between the team members. these people are rare... Don't buy anything from me! ITschak On Mon, Jun 3, 2019 at 9:29 PM Clark Morris wrote: > [Default] On 3 Jun 2019 09:41:54 -0700, in bit.listserv.ibm-main > sme...@gmu.edu (Seymour J Metz) wrote: > > >This whole thread has consistently confused several very different issues: > > I agree and have questions in each of the areas. > > > > 1. How secure is z/OS itself? > > I recall reading that Multics was more secure than the concurrent MVS > was at the time and wonder if that would have been a better base going > forward. Does the design of z/OS and the tools for implementation > make it more difficult to create and maintain a secure system? How > secure are VM and TPF relative to z/OS? Does anyone have a feel for > how secure and securable the Unisys and any other mainframe operating > systems are relative to z/OS? > > > > 2. How secure is 3rd party software? > > 30 years ago people were complain about some of the holes in CA > software. While much has changed and I assume those holes were > plugged long ago, the question remains as to how we evaluate 3rd party > software that by its nature has to have system hooks and run APF > authorized and / or key zero (system monitors, tape management > systems, etc.)? Could and should changes to z/OS be made that would > allow some of this software run unauthorized and key 8? How much > vulnerability do we introduce by having such things as monitors, > report management systems, etc? How much security and vulnerability > is at the application level where it is the application that has to > determine whether access is authorized (online banking anyone)? > > > > 3. How secure is the typical shop running z/OS? > > Given the need to consider security at not only the operating system > level but also the application level and the number of things that > have to be controlled, I suspect that most organizations are less > secure than they think they are. The problem starts with keeping the > authorities that people have current as they change roles in an > organization and leave that organization. Are the test system as > secure as the production systems? Have all of the people involved > including operators, people doing report distribution, application > developers and maintainers etc. been properly vetted? How do we > monitor to make sure people haveen't been compromised? The list goes > on. > > Clark Morris > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
>From an secure infrastructure view You can do everything right and have it go wrong. You can do everything wrong and never have an issue. Going forward, how do we make everything secure enough so a user writing down a password on a screen Post-it note, doesn't matter? I believe we have biometrics, but my experience shows problems with the cost, integrating it and manage it, beyond a small number of people. Then all the exceptions, both physical and ideological. "You can't put a chip in me." "Okay. Here wear this RFID badge around your neck. Always have it on, or else." "Or else what" "Bad employee, bad employee." -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, June 03, 2019 1:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls Certainly Multics as well hardened, and definitely more secure than contemporaneous MVS. I don't know how it compares to MVS in 2019. Multic would have been a better base going forward, but the S/360 architecture didn't have all of the facilities that would have been needed to port Multics. By the installation I don't mean just the software written or installed by the installation, but also the policies and enforcement. If key personnel are allow to write down passwords and leave them at their desks, don't expect to be invulnerable no matter how good the OS is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Monday, June 3, 2019 2:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [Default] On 3 Jun 2019 09:41:54 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >This whole thread has consistently confused several very different issues: I agree and have questions in each of the areas. > > 1. How secure is z/OS itself? I recall reading that Multics was more secure than the concurrent MVS was at the time and wonder if that would have been a better base going forward. Does the design of z/OS and the tools for implementation make it more difficult to create and maintain a secure system? How secure are VM and TPF relative to z/OS? Does anyone have a feel for how secure and securable the Unisys and any other mainframe operating systems are relative to z/OS? > > 2. How secure is 3rd party software? 30 years ago people were complain about some of the holes in CA software. While much has changed and I assume those holes were plugged long ago, the question remains as to how we evaluate 3rd party software that by its nature has to have system hooks and run APF authorized and / or key zero (system monitors, tape management systems, etc.)? Could and should changes to z/OS be made that would allow some of this software run unauthorized and key 8? How much vulnerability do we introduce by having such things as monitors, report management systems, etc? How much security and vulnerability is at the application level where it is the application that has to determine whether access is authorized (online banking anyone)? > > 3. How secure is the typical shop running z/OS? Given the need to consider security at not only the operating system level but also the application level and the number of things that have to be controlled, I suspect that most organizations are less secure than they think they are. The problem starts with keeping the authorities that people have current as they change roles in an organization and leave that organization. Are the test system as secure as the production systems? Have all of the people involved including operators, people doing report distribution, application developers and maintainers etc. been properly vetted? How do we monitor to make sure people haveen't been compromised? The list goes on. Clark Morris -- 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 DISCLAIMER: This email and any attachments may contain confidential information that is intended solely for use by the intended recipient(s). If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the communication. If you received this email in error, please contact the sender by reply email and immediately delete the communication. -- For IBM-MAIN subscribe / signoff / arc
Re: Just how secure are mainframes? | Trevor Eddolls
Certainly Multics as well hardened, and definitely more secure than contemporaneous MVS. I don't know how it compares to MVS in 2019. Multic would have been a better base going forward, but the S/360 architecture didn't have all of the facilities that would have been needed to port Multics. By the installation I don't mean just the software written or installed by the installation, but also the policies and enforcement. If key personnel are allow to write down passwords and leave them at their desks, don't expect to be invulnerable no matter how good the OS is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Monday, June 3, 2019 2:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [Default] On 3 Jun 2019 09:41:54 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >This whole thread has consistently confused several very different issues: I agree and have questions in each of the areas. > > 1. How secure is z/OS itself? I recall reading that Multics was more secure than the concurrent MVS was at the time and wonder if that would have been a better base going forward. Does the design of z/OS and the tools for implementation make it more difficult to create and maintain a secure system? How secure are VM and TPF relative to z/OS? Does anyone have a feel for how secure and securable the Unisys and any other mainframe operating systems are relative to z/OS? > > 2. How secure is 3rd party software? 30 years ago people were complain about some of the holes in CA software. While much has changed and I assume those holes were plugged long ago, the question remains as to how we evaluate 3rd party software that by its nature has to have system hooks and run APF authorized and / or key zero (system monitors, tape management systems, etc.)? Could and should changes to z/OS be made that would allow some of this software run unauthorized and key 8? How much vulnerability do we introduce by having such things as monitors, report management systems, etc? How much security and vulnerability is at the application level where it is the application that has to determine whether access is authorized (online banking anyone)? > > 3. How secure is the typical shop running z/OS? Given the need to consider security at not only the operating system level but also the application level and the number of things that have to be controlled, I suspect that most organizations are less secure than they think they are. The problem starts with keeping the authorities that people have current as they change roles in an organization and leave that organization. Are the test system as secure as the production systems? Have all of the people involved including operators, people doing report distribution, application developers and maintainers etc. been properly vetted? How do we monitor to make sure people haveen't been compromised? The list goes on. Clark Morris -- 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: Just how secure are mainframes? | Trevor Eddolls
[Default] On 3 Jun 2019 09:41:54 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >This whole thread has consistently confused several very different issues: I agree and have questions in each of the areas. > > 1. How secure is z/OS itself? I recall reading that Multics was more secure than the concurrent MVS was at the time and wonder if that would have been a better base going forward. Does the design of z/OS and the tools for implementation make it more difficult to create and maintain a secure system? How secure are VM and TPF relative to z/OS? Does anyone have a feel for how secure and securable the Unisys and any other mainframe operating systems are relative to z/OS? > > 2. How secure is 3rd party software? 30 years ago people were complain about some of the holes in CA software. While much has changed and I assume those holes were plugged long ago, the question remains as to how we evaluate 3rd party software that by its nature has to have system hooks and run APF authorized and / or key zero (system monitors, tape management systems, etc.)? Could and should changes to z/OS be made that would allow some of this software run unauthorized and key 8? How much vulnerability do we introduce by having such things as monitors, report management systems, etc? How much security and vulnerability is at the application level where it is the application that has to determine whether access is authorized (online banking anyone)? > > 3. How secure is the typical shop running z/OS? Given the need to consider security at not only the operating system level but also the application level and the number of things that have to be controlled, I suspect that most organizations are less secure than they think they are. The problem starts with keeping the authorities that people have current as they change roles in an organization and leave that organization. Are the test system as secure as the production systems? Have all of the people involved including operators, people doing report distribution, application developers and maintainers etc. been properly vetted? How do we monitor to make sure people haveen't been compromised? The list goes on. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
It's conceivable, but I doubt it. As best I can tell it's just a question of talking a cross purposes, not deliberate obfuscation. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> Sent: Sunday, June 2, 2019 5:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls He’s trying to sell his company’s security services. Something I thought was not allowed on this list. Sent from Yahoo Mail for iPhone On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > * As part of a APF authorized product there is a SVC or PC routine > that when called will turn on the JSBCAUTH bit Ouch! If it's APF authorized then why does it need to do that? And why would you allow such a vendor in the door? Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, or did you have to read the code like the rest of us? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ray Overby Sent: Friday, May 31, 2019 7:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls In response to "Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that IBM prevent key zero code from setting it? Why do think that turning on JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the installation doesn't control what goes into its authorized libraries then the vulnerability is in management, not in the platform." You are correct - MODESET does not set JSBCAUTH. What I meant to say is: Some of the vulnerabilities I have discovered in the wild will do the following: * As part of a APF authorized product there is a SVC or PC routine that when called will turn on the JSBCAUTH bit * Product application code (psw key 8 problem state not-apf authorized) will issue the SVC or PC to turn on JSCBAUTH bit * After control returns from SVC or PC routine the application program then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH bit is on this does not ABEND with S047 - MODESET works. * Application code will do "authorized stuff" * Application will invoke the SVC or PC routine to turn off the JSBCAUTH bit By dynamically turning on the JSCBAUTH bit allows the application to dynamically elevate its z/OS authority (ability to MODESET) which it would not normally be allowed to do. Disallowing this type of dynamic elevation of z/OS authority would make this kind of code logic unusable. It would force those that use this technique to adopt a different, more secure approach. On 5/31/2019 12:21 PM, Seymour J Metz wrote: >> The security code path can be modified (if it is non-rent), frontended by >> using content supervision functions (ex - task lib), or bypassed. > Sure, a user can front end parts of the application, he won't have access to > the production data. Of course, if installation management lets everybody and > his buddy alter the production JCL, then all bets are off, but then the > crackers don't need to front end the application. > >> * I don't know who Schiller is. Can you clarify? Thanks. > https://secure-web.cisco.com/1BhyjzGqq-589SlBQUb-IjJHHzwIrML_B3lxKqhUQGJUC3yoKaSXPASAjq408wXgHywuYnvh7nPmBEB8x9qeYTgkxsSPN0bNeQxHGTSJWT0rk5nVeYa_8emn94gln-C8ySnLBRQeWLZ_qOBqZkUTNLEAPtouZbZnym6YMqkcESxj3O8qFeA9Bpkk9VT8fPanX9_g_-uUniPy_oTilATJ4ZKgSv_cyg5IwH2jjpdLz9QUfhRWm-oaoUPCo28bfcg9hlCABe5muR1Y54CCiqwQD5dpSQe5XOOFUkUNFH85Shio44z6j2rrox7vuuIkx4qqEKW9l5JntIrQ2lYRpxCL7fm_DFgt1kxSE0rllIwhFqv1LC5ikE1Jk4JtFm0jTuu8X/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > https://secure-web.cisco.com/1JHQ5Q4uULSamxoCJBM5KqCgBYdAruW165Hn4Xd1Y4QQTSHehJj4Jwe6zJ3FES0pzkdssOb2l3YUKZIltYyzt6L6QwhR7I-bhe6I2XqEnHTVM5Qd6fKFCj8-5HL_2A1q0sO7Ux3S8rR1ki1upOlLLjwBz3HXkzkTTnYEI4hEZEepa6jj_wXwLMw_bbeZtUwCDJOGH892uh4AYyYjj2M9CLH6VzxoPAFdteTqkNYoR8KiZzbkKHgZdvcOkVMM8O2q2ukcBWOc7wp-Typ2YOqAoU8-DSq7RTrcwV2w-jA8CZ24UhcH4pBUYmFY-f5A1LL2bWBwKcCfl4KKoWz5-g_ksqf1OgjAfWeRu-2ubQVVgbS32TYwgCl2q_FtDMVbOPsMR/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Maid_of_Orleans_%28play%29 > >> * As an example - The platform could make a new integrity rule such >> as: Only SVC 107 can turn on JSCBAUTH bit. > Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose > that IBM prevent key zero code from setting it? Why do think that turning on > JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the > installation doesn't control what goes into its authorized libraries then the > vulnerability is in management, not in the platform. > > > > -- > Shmuel (Seymour J.) Metz > htt
Re: Just how secure are mainframes? | Trevor Eddolls
This whole thread has consistently confused several very different issues: 1. How secure is z/OS itself? 2. How secure is 3rd party software? 3. How secure is the typical shop running z/OS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Clark Morris Sent: Sunday, June 2, 2019 9:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s trying to sell his company’s security services. Something I thought was >not allowed on this list. > Whether or not he is selling something and I don't read his posts that way, he is making some valid points. As a retired MVS (I was back in applications by the time z/OS was available) systems programmer, I am far more skeptical about the invulnerability of z/OS. It is too easy to have decades old stuff still in a system in part because people don't know why it is there or are unaware of its existence. How much effort is required for an installation to achieve even 95 percent of the invulnerability that is theoretically possible and keep that up. How many holes are left in the average shop because people don't understand the implications of all of both IBM and vendor defaults where I will almost guarantee that there are at some defaults that leave a system open to hacking. I think that it is difficult to understand all of the implications of an action. Many shops may be running exits or other systems modifications that have worked for decades and because they work, no one has checked them to see if they have an unintended vulnerability. I hope that none of my code that is on file 432 of the CBT Tape (Philips light mods) has any vulnerability but the thing that scares me is that I might not be smart enough to find it even if I was looking for it. Good security isn't cheap. Z/OS may be the most secure starting base but it requires real effort to actually implement it with both good security and good usability. How much vulnerability is there in the test systems? How much are the systems programmer sandboxes exposed to the outside world? What uncertainties exist in systems vendor code? Are organizations willing or able to periodically test their systems' vulnerabilities? Can be secure does not mean is secure? Clark Morris > >Sent from Yahoo Mail for iPhone > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> * As part of a APF authorized product there is a SVC or PC routine >> that when called will turn on the JSBCAUTH bit > >Ouch! > >If it's APF authorized then why does it need to do that? And why would you >allow such a vendor in the door? > >Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >or did you have to read the code like the rest of us? -- 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: Just how secure are mainframes? | Trevor Eddolls
[Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >Hes selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>Hes trying to sell his companys security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other systems modifications that have worked for >decades and because they work, no one has checked them to see if they >have an unintended vulnerability. I hope that none of my code that is >on file 432 of the CBT Tape (Philips light mods) has any vulnerability >but the thing that scares me is that I might not be smart enough to >find it even if I was looking for it. Good security isn't cheap. Z/OS >may be the most secure starting base but it requires real effort to >actually implement it with both good security and good usability. How >much vulnerability is there in the test systems? How much are the >systems programmer sandboxes exposed to the outside world? What >uncertainties exist in systems vendor code? Are organizations willing >or able to periodically test their systems' vulnerabilities? Can be >secure does not mean is secure? > >Clark Morris >> >>Sent from Yahoo Mail for iPhone >> >> >>On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: >> >>> * As part of a APF authorized product there is a SVC or PC routine >>> that when called will turn on the JSBCAUTH bit >> >>Ouch! >> >>If it's APF authorized then why does it need to do that? And why would you >>allow such a vendor in the door? >> >>Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >>or did you have to read the code like the rest of us? > >-- >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: Just how secure are mainframes? | Trevor Eddolls
The only one selling here is you. You are selling BS and we are not buying it. Remember, according to you, we known it all. So why do you continue? I'll take Ray's intentions over yours *every single time*. He has earned it from this industry many times over. Just because he has had security products that sell over the decades does not mean he can't be a trusted source for answers relating to security, ACF2, Pen testing, etc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Sunday, June 02, 2019 10:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will even show you in application code. Then no doubt analyze your application code for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it is inherently (by design) more secure than any other platform. And, a major reason why almost every bank, insurance company, and major retailers still have them. Sent from Yahoo Mail for iPhone On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s trying to sell his company’s security services. Something I thought was >not allowed on this list. > Whether or not he is selling something and I don't read his posts that way, he is making some valid points. As a retired MVS (I was back in applications by the time z/OS was available) systems programmer, I am far more skeptical about the invulnerability of z/OS. It is too easy to have decades old stuff still in a system in part because people don't know why it is there or are unaware of its existence. How much effort is required for an installation to achieve even 95 percent of the invulnerability that is theoretically possible and keep that up. How many holes are left in the average shop because people don't understand the implications of all of both IBM and vendor defaults where I will almost guarantee that there are at some defaults that leave a system open to hacking. I think that it is difficult to understand all of the implications of an action. Many shops may be running exits or other systems modifications that have worked for decades and because they work, no one has checked them to see if they have an unintended vulnerability. I hope that none of my code that is on file 432 of the CBT Tape (Philips light mods) has any vulnerability but the thing that scares me is that I might not be smart enough to find it even if I was looking for it. Good security isn't cheap. Z/OS may be the most secure starting base but it requires real effort to actually implement it with both good security and good usability. How much vulnerability is there in the test systems? How much are the systems programmer sandboxes exposed to the outside world? What uncertainties exist in systems vendor code? Are organizations willing or able to periodically test their systems' vulnerabilities? Can be secure does not mean is secure? Clark Morris > >Sent from Yahoo Mail for iPhone > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> * As part of a APF authorized product there is a SVC or PC routine >> that when called will turn on the JSBCAUTH bit > >Ouch! > >If it's APF authorized then why does it need to do that? And why would you >allow such a vendor in the door? > >Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >or did you have to read the code like the rest of us? -- 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: Just how secure are mainframes? | Trevor Eddolls
I do? You must be joking. The thread is monopolized by one person. You know who. ITschak בתאריך יום ב׳, 3 ביוני 2019, 0:47, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > He’s trying to sell his company’s security services. Something I thought > was not allowed on this list. > > > Sent from Yahoo Mail for iPhone > > > On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > > > * As part of a APF authorized product there is a SVC or PC routine > >that when called will turn on the JSBCAUTH bit > > Ouch! > > If it's APF authorized then why does it need to do that? And why would you > allow such a vendor in the door? > > Did you have a tool that discovered that the vendor's SVC turned on > JSCBAUTH, or did you have to read the code like the rest of us? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Ray Overby > Sent: Friday, May 31, 2019 7:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > In response to "Since when does MODESET turn on the JSCBAUTH bit? Just > how do you propose that IBM prevent key zero code from setting it? Why > do think that turning on JSCBAUTH lets key zero code do anything that it > couldn't do anyways? If the installation doesn't control what goes into > its authorized libraries then the vulnerability is in management, not in > the platform." > > You are correct - MODESET does not set JSBCAUTH. What I meant to say is: > > Some of the vulnerabilities I have discovered in the wild will do the > following: > > * As part of a APF authorized product there is a SVC or PC routine > that when called will turn on the JSBCAUTH bit > * Product application code (psw key 8 problem state not-apf > authorized) will issue the SVC or PC to turn on JSCBAUTH bit > * After control returns from SVC or PC routine the application program > then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH > bit is on this does not ABEND with S047 - MODESET works. > * Application code will do "authorized stuff" > * Application will invoke the SVC or PC routine to turn off the > JSBCAUTH bit > > By dynamically turning on the JSCBAUTH bit allows the application to > dynamically elevate its z/OS authority (ability to MODESET) which it > would not normally be allowed to do. Disallowing this type of dynamic > elevation of z/OS authority would make this kind of code logic unusable. > It would force those that use this technique to adopt a different, more > secure approach. > > > On 5/31/2019 12:21 PM, Seymour J Metz wrote: > >> The security code path can be modified (if it is non-rent), frontended > by using content supervision functions (ex - task lib), or bypassed. > > Sure, a user can front end parts of the application, he won't have > access to the production data. Of course, if installation management lets > everybody and his buddy alter the production JCL, then all bets are off, > but then the crackers don't need to front end the application. > > > >>* I don't know who Schiller is. Can you clarify? Thanks. > > > https://secure-web.cisco.com/1BhyjzGqq-589SlBQUb-IjJHHzwIrML_B3lxKqhUQGJUC3yoKaSXPASAjq408wXgHywuYnvh7nPmBEB8x9qeYTgkxsSPN0bNeQxHGTSJWT0rk5nVeYa_8emn94gln-C8ySnLBRQeWLZ_qOBqZkUTNLEAPtouZbZnym6YMqkcESxj3O8qFeA9Bpkk9VT8fPanX9_g_-uUniPy_oTilATJ4ZKgSv_cyg5IwH2jjpdLz9QUfhRWm-oaoUPCo28bfcg9hlCABe5muR1Y54CCiqwQD5dpSQe5XOOFUkUNFH85Shio44z6j2rrox7vuuIkx4qqEKW9l5JntIrQ2lYRpxCL7fm_DFgt1kxSE0rllIwhFqv1LC5ikE1Jk4JtFm0jTuu8X/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > > > https://secure-web.cisco.com/1JHQ5Q4uULSamxoCJBM5KqCgBYdAruW165Hn4Xd1Y4QQTSHehJj4Jwe6zJ3FES0pzkdssOb2l3YUKZIltYyzt6L6QwhR7I-bhe6I2XqEnHTVM5Qd6fKFCj8-5HL_2A1q0sO7Ux3S8rR1ki1upOlLLjwBz3HXkzkTTnYEI4hEZEepa6jj_wXwLMw_bbeZtUwCDJOGH892uh4AYyYjj2M9CLH6VzxoPAFdteTqkNYoR8KiZzbkKHgZdvcOkVMM8O2q2ukcBWOc7wp-Typ2YOqAoU8-DSq7RTrcwV2w-jA8CZ24UhcH4pBUYmFY-f5A1LL2bWBwKcCfl4KKoWz5-g_ksqf1OgjAfWeRu-2ubQVVgbS32TYwgCl2q_FtDMVbOPsMR/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Maid_of_Orleans_%28play%29 > > > >>* As an example - The platform could make a new integrity rule such > >>as: Only SVC 107 can turn on JSCBAUTH bit. > > Since when does MODESET turn on the JSCBAUTH bit? Just how do you > propose that IBM prevent key zero code from setting it? Why do think that > turning on JSCBAUTH lets key zero code do anything that it couldn't do > anyways? If the installation doesn't control what goes into its authorized > libraries then the vulnerability is in management, not in the platform. &g
Re: Just how secure are mainframes? | Trevor Eddolls
He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will even show you in application code. Then no doubt analyze your application code for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it is inherently (by design) more secure than any other platform. And, a major reason why almost every bank, insurance company, and major retailers still have them. Sent from Yahoo Mail for iPhone On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s trying to sell his company’s security services. Something I thought was >not allowed on this list. > Whether or not he is selling something and I don't read his posts that way, he is making some valid points. As a retired MVS (I was back in applications by the time z/OS was available) systems programmer, I am far more skeptical about the invulnerability of z/OS. It is too easy to have decades old stuff still in a system in part because people don't know why it is there or are unaware of its existence. How much effort is required for an installation to achieve even 95 percent of the invulnerability that is theoretically possible and keep that up. How many holes are left in the average shop because people don't understand the implications of all of both IBM and vendor defaults where I will almost guarantee that there are at some defaults that leave a system open to hacking. I think that it is difficult to understand all of the implications of an action. Many shops may be running exits or other systems modifications that have worked for decades and because they work, no one has checked them to see if they have an unintended vulnerability. I hope that none of my code that is on file 432 of the CBT Tape (Philips light mods) has any vulnerability but the thing that scares me is that I might not be smart enough to find it even if I was looking for it. Good security isn't cheap. Z/OS may be the most secure starting base but it requires real effort to actually implement it with both good security and good usability. How much vulnerability is there in the test systems? How much are the systems programmer sandboxes exposed to the outside world? What uncertainties exist in systems vendor code? Are organizations willing or able to periodically test their systems' vulnerabilities? Can be secure does not mean is secure? Clark Morris > >Sent from Yahoo Mail for iPhone > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> * As part of a APF authorized product there is a SVC or PC routine >> that when called will turn on the JSBCAUTH bit > >Ouch! > >If it's APF authorized then why does it need to do that? And why would you >allow such a vendor in the door? > >Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >or did you have to read the code like the rest of us? -- 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: Just how secure are mainframes? | Trevor Eddolls
[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >Hes trying to sell his companys security services. Something I thought was >not allowed on this list. > Whether or not he is selling something and I don't read his posts that way, he is making some valid points. As a retired MVS (I was back in applications by the time z/OS was available) systems programmer, I am far more skeptical about the invulnerability of z/OS. It is too easy to have decades old stuff still in a system in part because people don't know why it is there or are unaware of its existence. How much effort is required for an installation to achieve even 95 percent of the invulnerability that is theoretically possible and keep that up. How many holes are left in the average shop because people don't understand the implications of all of both IBM and vendor defaults where I will almost guarantee that there are at some defaults that leave a system open to hacking. I think that it is difficult to understand all of the implications of an action. Many shops may be running exits or other systems modifications that have worked for decades and because they work, no one has checked them to see if they have an unintended vulnerability. I hope that none of my code that is on file 432 of the CBT Tape (Philips light mods) has any vulnerability but the thing that scares me is that I might not be smart enough to find it even if I was looking for it. Good security isn't cheap. Z/OS may be the most secure starting base but it requires real effort to actually implement it with both good security and good usability. How much vulnerability is there in the test systems? How much are the systems programmer sandboxes exposed to the outside world? What uncertainties exist in systems vendor code? Are organizations willing or able to periodically test their systems' vulnerabilities? Can be secure does not mean is secure? Clark Morris > >Sent from Yahoo Mail for iPhone > > >On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > >> * As part of a APF authorized product there is a SVC or PC routine >> that when called will turn on the JSBCAUTH bit > >Ouch! > >If it's APF authorized then why does it need to do that? And why would you >allow such a vendor in the door? > >Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, >or did you have to read the code like the rest of us? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
He’s trying to sell his company’s security services. Something I thought was not allowed on this list. Sent from Yahoo Mail for iPhone On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: > * As part of a APF authorized product there is a SVC or PC routine > that when called will turn on the JSBCAUTH bit Ouch! If it's APF authorized then why does it need to do that? And why would you allow such a vendor in the door? Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, or did you have to read the code like the rest of us? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ray Overby Sent: Friday, May 31, 2019 7:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls In response to "Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that IBM prevent key zero code from setting it? Why do think that turning on JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the installation doesn't control what goes into its authorized libraries then the vulnerability is in management, not in the platform." You are correct - MODESET does not set JSBCAUTH. What I meant to say is: Some of the vulnerabilities I have discovered in the wild will do the following: * As part of a APF authorized product there is a SVC or PC routine that when called will turn on the JSBCAUTH bit * Product application code (psw key 8 problem state not-apf authorized) will issue the SVC or PC to turn on JSCBAUTH bit * After control returns from SVC or PC routine the application program then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH bit is on this does not ABEND with S047 - MODESET works. * Application code will do "authorized stuff" * Application will invoke the SVC or PC routine to turn off the JSBCAUTH bit By dynamically turning on the JSCBAUTH bit allows the application to dynamically elevate its z/OS authority (ability to MODESET) which it would not normally be allowed to do. Disallowing this type of dynamic elevation of z/OS authority would make this kind of code logic unusable. It would force those that use this technique to adopt a different, more secure approach. On 5/31/2019 12:21 PM, Seymour J Metz wrote: >> The security code path can be modified (if it is non-rent), frontended by >> using content supervision functions (ex - task lib), or bypassed. > Sure, a user can front end parts of the application, he won't have access to > the production data. Of course, if installation management lets everybody and > his buddy alter the production JCL, then all bets are off, but then the > crackers don't need to front end the application. > >> * I don't know who Schiller is. Can you clarify? Thanks. > https://secure-web.cisco.com/1BhyjzGqq-589SlBQUb-IjJHHzwIrML_B3lxKqhUQGJUC3yoKaSXPASAjq408wXgHywuYnvh7nPmBEB8x9qeYTgkxsSPN0bNeQxHGTSJWT0rk5nVeYa_8emn94gln-C8ySnLBRQeWLZ_qOBqZkUTNLEAPtouZbZnym6YMqkcESxj3O8qFeA9Bpkk9VT8fPanX9_g_-uUniPy_oTilATJ4ZKgSv_cyg5IwH2jjpdLz9QUfhRWm-oaoUPCo28bfcg9hlCABe5muR1Y54CCiqwQD5dpSQe5XOOFUkUNFH85Shio44z6j2rrox7vuuIkx4qqEKW9l5JntIrQ2lYRpxCL7fm_DFgt1kxSE0rllIwhFqv1LC5ikE1Jk4JtFm0jTuu8X/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > https://secure-web.cisco.com/1JHQ5Q4uULSamxoCJBM5KqCgBYdAruW165Hn4Xd1Y4QQTSHehJj4Jwe6zJ3FES0pzkdssOb2l3YUKZIltYyzt6L6QwhR7I-bhe6I2XqEnHTVM5Qd6fKFCj8-5HL_2A1q0sO7Ux3S8rR1ki1upOlLLjwBz3HXkzkTTnYEI4hEZEepa6jj_wXwLMw_bbeZtUwCDJOGH892uh4AYyYjj2M9CLH6VzxoPAFdteTqkNYoR8KiZzbkKHgZdvcOkVMM8O2q2ukcBWOc7wp-Typ2YOqAoU8-DSq7RTrcwV2w-jA8CZ24UhcH4pBUYmFY-f5A1LL2bWBwKcCfl4KKoWz5-g_ksqf1OgjAfWeRu-2ubQVVgbS32TYwgCl2q_FtDMVbOPsMR/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Maid_of_Orleans_%28play%29 > >> * As an example - The platform could make a new integrity rule such >> as: Only SVC 107 can turn on JSCBAUTH bit. > Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose > that IBM prevent key zero code from setting it? Why do think that turning on > JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the > installation doesn't control what goes into its authorized libraries then the > vulnerability is in management, not in the platform. > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Jesse 1 Robinson > Sent: Thursday, May 30, 2019 5:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > It must be Friday somewhere. I put 'against stupidity' into Google. > Schiller's exact quote popped up first. Just sayin'. > > . > . > J.O.Skip Robinson >
Re: Just how secure are mainframes? | Trevor Eddolls
> * As part of a APF authorized product there is a SVC or PC routine >that when called will turn on the JSBCAUTH bit Ouch! If it's APF authorized then why does it need to do that? And why would you allow such a vendor in the door? Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, or did you have to read the code like the rest of us? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ray Overby Sent: Friday, May 31, 2019 7:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls In response to "Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that IBM prevent key zero code from setting it? Why do think that turning on JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the installation doesn't control what goes into its authorized libraries then the vulnerability is in management, not in the platform." You are correct - MODESET does not set JSBCAUTH. What I meant to say is: Some of the vulnerabilities I have discovered in the wild will do the following: * As part of a APF authorized product there is a SVC or PC routine that when called will turn on the JSBCAUTH bit * Product application code (psw key 8 problem state not-apf authorized) will issue the SVC or PC to turn on JSCBAUTH bit * After control returns from SVC or PC routine the application program then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH bit is on this does not ABEND with S047 - MODESET works. * Application code will do "authorized stuff" * Application will invoke the SVC or PC routine to turn off the JSBCAUTH bit By dynamically turning on the JSCBAUTH bit allows the application to dynamically elevate its z/OS authority (ability to MODESET) which it would not normally be allowed to do. Disallowing this type of dynamic elevation of z/OS authority would make this kind of code logic unusable. It would force those that use this technique to adopt a different, more secure approach. On 5/31/2019 12:21 PM, Seymour J Metz wrote: >> The security code path can be modified (if it is non-rent), frontended by >> using content supervision functions (ex - task lib), or bypassed. > Sure, a user can front end parts of the application, he won't have access to > the production data. Of course, if installation management lets everybody and > his buddy alter the production JCL, then all bets are off, but then the > crackers don't need to front end the application. > >>* I don't know who Schiller is. Can you clarify? Thanks. > https://secure-web.cisco.com/1BhyjzGqq-589SlBQUb-IjJHHzwIrML_B3lxKqhUQGJUC3yoKaSXPASAjq408wXgHywuYnvh7nPmBEB8x9qeYTgkxsSPN0bNeQxHGTSJWT0rk5nVeYa_8emn94gln-C8ySnLBRQeWLZ_qOBqZkUTNLEAPtouZbZnym6YMqkcESxj3O8qFeA9Bpkk9VT8fPanX9_g_-uUniPy_oTilATJ4ZKgSv_cyg5IwH2jjpdLz9QUfhRWm-oaoUPCo28bfcg9hlCABe5muR1Y54CCiqwQD5dpSQe5XOOFUkUNFH85Shio44z6j2rrox7vuuIkx4qqEKW9l5JntIrQ2lYRpxCL7fm_DFgt1kxSE0rllIwhFqv1LC5ikE1Jk4JtFm0jTuu8X/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > https://secure-web.cisco.com/1JHQ5Q4uULSamxoCJBM5KqCgBYdAruW165Hn4Xd1Y4QQTSHehJj4Jwe6zJ3FES0pzkdssOb2l3YUKZIltYyzt6L6QwhR7I-bhe6I2XqEnHTVM5Qd6fKFCj8-5HL_2A1q0sO7Ux3S8rR1ki1upOlLLjwBz3HXkzkTTnYEI4hEZEepa6jj_wXwLMw_bbeZtUwCDJOGH892uh4AYyYjj2M9CLH6VzxoPAFdteTqkNYoR8KiZzbkKHgZdvcOkVMM8O2q2ukcBWOc7wp-Typ2YOqAoU8-DSq7RTrcwV2w-jA8CZ24UhcH4pBUYmFY-f5A1LL2bWBwKcCfl4KKoWz5-g_ksqf1OgjAfWeRu-2ubQVVgbS32TYwgCl2q_FtDMVbOPsMR/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Maid_of_Orleans_%28play%29 > >>* As an example - The platform could make a new integrity rule such >> as: Only SVC 107 can turn on JSCBAUTH bit. > Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose > that IBM prevent key zero code from setting it? Why do think that turning on > JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the > installation doesn't control what goes into its authorized libraries then the > vulnerability is in management, not in the platform. > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Jesse 1 Robinson > Sent: Thursday, May 30, 2019 5:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > It must be Friday somewhere. I put 'against stupidity' into Google. > Schiller's exact quote popped up first. Just sayin'. > > . > . > 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 > > -
Re: Just how secure are mainframes? | Trevor Eddolls
You're missing the point: there is no such SVC in the dispute. What is at issue is the ability to detect key zero code that turns on JSCBAUTH, not the ability to install trap doors. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Sunday, June 2, 2019 3:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls Sory to inform you: there are such SVCs available for download. I think there is one on the cbttape . בתאריך יום א׳, 2 ביוני 2019, 22:33, מאת Seymour J Metz : > > We look for such SVC > > There is no "such SVC". What is under discussion is code that runs > legitimately in key zero tuning on JSCBAUTH, not an SVC that does that. > > IMHO, for 3rd party vendor that requires APF to use that to turn on > JSCBAUTH is grossly irresponsible, and I'd love for you to catch such a > vendor. I just don't believe that it is possible short of reading the code > thoroughly. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of ITschak Mugzach > Sent: Saturday, June 1, 2019 2:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > We look for such SVC in our STIG compliance product IronSphere. We advise > adding ESM control in facility class to control who can use it in case this > SVC is a must. > > ITschak > > בתאריך שבת, 1 ביוני 2019, 2:19, מאת Ray Overby : > > > In response to "Since when does MODESET turn on the JSCBAUTH bit? Just > > how do you propose that IBM prevent key zero code from setting it? Why > > do think that turning on JSCBAUTH lets key zero code do anything that it > > couldn't do anyways? If the installation doesn't control what goes into > > its authorized libraries then the vulnerability is in management, not in > > the platform." > > > > You are correct - MODESET does not set JSBCAUTH. What I meant to say is: > > > > Some of the vulnerabilities I have discovered in the wild will do the > > following: > > > > * As part of a APF authorized product there is a SVC or PC routine > > that when called will turn on the JSBCAUTH bit > > * Product application code (psw key 8 problem state not-apf > > authorized) will issue the SVC or PC to turn on JSCBAUTH bit > > * After control returns from SVC or PC routine the application program > > then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH > > bit is on this does not ABEND with S047 - MODESET works. > > * Application code will do "authorized stuff" > > * Application will invoke the SVC or PC routine to turn off the > > JSBCAUTH bit > > > > By dynamically turning on the JSCBAUTH bit allows the application to > > dynamically elevate its z/OS authority (ability to MODESET) which it > > would not normally be allowed to do. Disallowing this type of dynamic > > elevation of z/OS authority would make this kind of code logic unusable. > > It would force those that use this technique to adopt a different, more > > secure approach. > > > > > > On 5/31/2019 12:21 PM, Seymour J Metz wrote: > > >> The security code path can be modified (if it is non-rent), frontended > > by using content supervision functions (ex - task lib), or bypassed. > > > Sure, a user can front end parts of the application, he won't have > > access to the production data. Of course, if installation management lets > > everybody and his buddy alter the production JCL, then all bets are off, > > but then the crackers don't need to front end the application. > > > > > >>* I don't know who Schiller is. Can you clarify? Thanks. > > > > https://secure-web.cisco.com/1c4OrmAe9KnhmZx8g9sBxlSsv-hIMbNz9UGjkio7TFzPajz6dlrUSWmHtQ00ppd4Fo67mAAWdaKVO92JLY29NoiDxrsi6xZFpNHQz5arBb1KY5RGDAEMESUo0ynBKZ91aPA_lJJ7s46fljALKFJiHA_veVLbCfDmlaNNyl40LTbhwPVSTPN86pIC6qJ8UmPJAi92ayGPAiQ1tP31vCnOEawBhkAkgyIpNL9uGlDcKflPs0P7TdTPCGIjqSETQACespkocZvWIs4yFILQdq9mZgskwJdZf3PHQtKObFdT1UFxGzAIKky9e8MZuJKx_vM8wJjpUJpGWZqSxV7qeX6GUG7Czsd3IdESStaKEUWyRzPtjanZB5KZbQddfyedqsCmB5uxptJVkBnPZ1CQAqRPltIdY5X0AMprTvq-d5fEuEtu_VdOOpBcamTO_hgAhzgdq/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > > > > https://secure-web.cisco.com/1QQeEhpQJLEg-12skT-aktu0983OzbgoTd4Kbnku6kDsj5fkW3LPONrHhE04xCfPJd_FqQmAXTb-iszk7K5aCq-8p62_YCZIUj3EaGue4KQjQVizQ88-fWoXyyVYpxOInRR66ucRqUnEo7sbJct4tc0u5oCMWJmINWIDeptbhjhyMBeR_BFGKB_GIOIoaGh-czVK2yjvy0mYcVzzdANX6e5G7MBauV0gXRY0ua
Re: Just how secure are mainframes? | Trevor Eddolls
Sory to inform you: there are such SVCs available for download. I think there is one on the cbttape . בתאריך יום א׳, 2 ביוני 2019, 22:33, מאת Seymour J Metz : > > We look for such SVC > > There is no "such SVC". What is under discussion is code that runs > legitimately in key zero tuning on JSCBAUTH, not an SVC that does that. > > IMHO, for 3rd party vendor that requires APF to use that to turn on > JSCBAUTH is grossly irresponsible, and I'd love for you to catch such a > vendor. I just don't believe that it is possible short of reading the code > thoroughly. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of ITschak Mugzach > Sent: Saturday, June 1, 2019 2:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > We look for such SVC in our STIG compliance product IronSphere. We advise > adding ESM control in facility class to control who can use it in case this > SVC is a must. > > ITschak > > בתאריך שבת, 1 ביוני 2019, 2:19, מאת Ray Overby : > > > In response to "Since when does MODESET turn on the JSCBAUTH bit? Just > > how do you propose that IBM prevent key zero code from setting it? Why > > do think that turning on JSCBAUTH lets key zero code do anything that it > > couldn't do anyways? If the installation doesn't control what goes into > > its authorized libraries then the vulnerability is in management, not in > > the platform." > > > > You are correct - MODESET does not set JSBCAUTH. What I meant to say is: > > > > Some of the vulnerabilities I have discovered in the wild will do the > > following: > > > > * As part of a APF authorized product there is a SVC or PC routine > > that when called will turn on the JSBCAUTH bit > > * Product application code (psw key 8 problem state not-apf > > authorized) will issue the SVC or PC to turn on JSCBAUTH bit > > * After control returns from SVC or PC routine the application program > > then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH > > bit is on this does not ABEND with S047 - MODESET works. > > * Application code will do "authorized stuff" > > * Application will invoke the SVC or PC routine to turn off the > > JSBCAUTH bit > > > > By dynamically turning on the JSCBAUTH bit allows the application to > > dynamically elevate its z/OS authority (ability to MODESET) which it > > would not normally be allowed to do. Disallowing this type of dynamic > > elevation of z/OS authority would make this kind of code logic unusable. > > It would force those that use this technique to adopt a different, more > > secure approach. > > > > > > On 5/31/2019 12:21 PM, Seymour J Metz wrote: > > >> The security code path can be modified (if it is non-rent), frontended > > by using content supervision functions (ex - task lib), or bypassed. > > > Sure, a user can front end parts of the application, he won't have > > access to the production data. Of course, if installation management lets > > everybody and his buddy alter the production JCL, then all bets are off, > > but then the crackers don't need to front end the application. > > > > > >>* I don't know who Schiller is. Can you clarify? Thanks. > > > > https://secure-web.cisco.com/1c4OrmAe9KnhmZx8g9sBxlSsv-hIMbNz9UGjkio7TFzPajz6dlrUSWmHtQ00ppd4Fo67mAAWdaKVO92JLY29NoiDxrsi6xZFpNHQz5arBb1KY5RGDAEMESUo0ynBKZ91aPA_lJJ7s46fljALKFJiHA_veVLbCfDmlaNNyl40LTbhwPVSTPN86pIC6qJ8UmPJAi92ayGPAiQ1tP31vCnOEawBhkAkgyIpNL9uGlDcKflPs0P7TdTPCGIjqSETQACespkocZvWIs4yFILQdq9mZgskwJdZf3PHQtKObFdT1UFxGzAIKky9e8MZuJKx_vM8wJjpUJpGWZqSxV7qeX6GUG7Czsd3IdESStaKEUWyRzPtjanZB5KZbQddfyedqsCmB5uxptJVkBnPZ1CQAqRPltIdY5X0AMprTvq-d5fEuEtu_VdOOpBcamTO_hgAhzgdq/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > > > > https://secure-web.cisco.com/1QQeEhpQJLEg-12skT-aktu0983OzbgoTd4Kbnku6kDsj5fkW3LPONrHhE04xCfPJd_FqQmAXTb-iszk7K5aCq-8p62_YCZIUj3EaGue4KQjQVizQ88-fWoXyyVYpxOInRR66ucRqUnEo7sbJct4tc0u5oCMWJmINWIDeptbhjhyMBeR_BFGKB_GIOIoaGh-czVK2yjvy0mYcVzzdANX6e5G7MBauV0gXRY0uaTy1aNYSQu5-COzF-KQk7jwwNbFfhQxHLChlwJe7hFapIM4ceqyHtI1QjilX0nTyfXBQOZ2CpkSiymI4TOC7j1Has2tfDxkXE-c5ycyz-HtkPBrvFVXUDwyTOiZx2O7CkuyhgQY6DFzUJsZJZbCz15xM7FZsiPZJSl8gfBVHtpOzbJi86cZ9GBqbKz959GlbBICgcEJEFr5UsBlXIhEP38FPU4Dw/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Maid_of_Orleans_%28play%29 > > > > > >>* As an example - The platform could make a new integrity rule such > > >> as: Only SVC 107 can turn on JSCBAUTH bit. > > >
Re: Just how secure are mainframes? | Trevor Eddolls
> We look for such SVC There is no "such SVC". What is under discussion is code that runs legitimately in key zero tuning on JSCBAUTH, not an SVC that does that. IMHO, for 3rd party vendor that requires APF to use that to turn on JSCBAUTH is grossly irresponsible, and I'd love for you to catch such a vendor. I just don't believe that it is possible short of reading the code thoroughly. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Saturday, June 1, 2019 2:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls We look for such SVC in our STIG compliance product IronSphere. We advise adding ESM control in facility class to control who can use it in case this SVC is a must. ITschak בתאריך שבת, 1 ביוני 2019, 2:19, מאת Ray Overby : > In response to "Since when does MODESET turn on the JSCBAUTH bit? Just > how do you propose that IBM prevent key zero code from setting it? Why > do think that turning on JSCBAUTH lets key zero code do anything that it > couldn't do anyways? If the installation doesn't control what goes into > its authorized libraries then the vulnerability is in management, not in > the platform." > > You are correct - MODESET does not set JSBCAUTH. What I meant to say is: > > Some of the vulnerabilities I have discovered in the wild will do the > following: > > * As part of a APF authorized product there is a SVC or PC routine > that when called will turn on the JSBCAUTH bit > * Product application code (psw key 8 problem state not-apf > authorized) will issue the SVC or PC to turn on JSCBAUTH bit > * After control returns from SVC or PC routine the application program > then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH > bit is on this does not ABEND with S047 - MODESET works. > * Application code will do "authorized stuff" > * Application will invoke the SVC or PC routine to turn off the > JSBCAUTH bit > > By dynamically turning on the JSCBAUTH bit allows the application to > dynamically elevate its z/OS authority (ability to MODESET) which it > would not normally be allowed to do. Disallowing this type of dynamic > elevation of z/OS authority would make this kind of code logic unusable. > It would force those that use this technique to adopt a different, more > secure approach. > > > On 5/31/2019 12:21 PM, Seymour J Metz wrote: > >> The security code path can be modified (if it is non-rent), frontended > by using content supervision functions (ex - task lib), or bypassed. > > Sure, a user can front end parts of the application, he won't have > access to the production data. Of course, if installation management lets > everybody and his buddy alter the production JCL, then all bets are off, > but then the crackers don't need to front end the application. > > > >>* I don't know who Schiller is. Can you clarify? Thanks. > > https://secure-web.cisco.com/1c4OrmAe9KnhmZx8g9sBxlSsv-hIMbNz9UGjkio7TFzPajz6dlrUSWmHtQ00ppd4Fo67mAAWdaKVO92JLY29NoiDxrsi6xZFpNHQz5arBb1KY5RGDAEMESUo0ynBKZ91aPA_lJJ7s46fljALKFJiHA_veVLbCfDmlaNNyl40LTbhwPVSTPN86pIC6qJ8UmPJAi92ayGPAiQ1tP31vCnOEawBhkAkgyIpNL9uGlDcKflPs0P7TdTPCGIjqSETQACespkocZvWIs4yFILQdq9mZgskwJdZf3PHQtKObFdT1UFxGzAIKky9e8MZuJKx_vM8wJjpUJpGWZqSxV7qeX6GUG7Czsd3IdESStaKEUWyRzPtjanZB5KZbQddfyedqsCmB5uxptJVkBnPZ1CQAqRPltIdY5X0AMprTvq-d5fEuEtu_VdOOpBcamTO_hgAhzgdq/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > > https://secure-web.cisco.com/1QQeEhpQJLEg-12skT-aktu0983OzbgoTd4Kbnku6kDsj5fkW3LPONrHhE04xCfPJd_FqQmAXTb-iszk7K5aCq-8p62_YCZIUj3EaGue4KQjQVizQ88-fWoXyyVYpxOInRR66ucRqUnEo7sbJct4tc0u5oCMWJmINWIDeptbhjhyMBeR_BFGKB_GIOIoaGh-czVK2yjvy0mYcVzzdANX6e5G7MBauV0gXRY0uaTy1aNYSQu5-COzF-KQk7jwwNbFfhQxHLChlwJe7hFapIM4ceqyHtI1QjilX0nTyfXBQOZ2CpkSiymI4TOC7j1Has2tfDxkXE-c5ycyz-HtkPBrvFVXUDwyTOiZx2O7CkuyhgQY6DFzUJsZJZbCz15xM7FZsiPZJSl8gfBVHtpOzbJi86cZ9GBqbKz959GlbBICgcEJEFr5UsBlXIhEP38FPU4Dw/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Maid_of_Orleans_%28play%29 > > > >>* As an example - The platform could make a new integrity rule such > >> as: Only SVC 107 can turn on JSCBAUTH bit. > > Since when does MODESET turn on the JSCBAUTH bit? Just how do you > propose that IBM prevent key zero code from setting it? Why do think that > turning on JSCBAUTH lets key zero code do anything that it couldn't do > anyways? If the installation doesn't control what goes into its authorized > libraries then the vulnerability is in management, not in the platform. > > > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > >
Re: Just how secure are mainframes? | Trevor Eddolls
We look for such SVC in our STIG compliance product IronSphere. We advise adding ESM control in facility class to control who can use it in case this SVC is a must. ITschak בתאריך שבת, 1 ביוני 2019, 2:19, מאת Ray Overby : > In response to "Since when does MODESET turn on the JSCBAUTH bit? Just > how do you propose that IBM prevent key zero code from setting it? Why > do think that turning on JSCBAUTH lets key zero code do anything that it > couldn't do anyways? If the installation doesn't control what goes into > its authorized libraries then the vulnerability is in management, not in > the platform." > > You are correct - MODESET does not set JSBCAUTH. What I meant to say is: > > Some of the vulnerabilities I have discovered in the wild will do the > following: > > * As part of a APF authorized product there is a SVC or PC routine > that when called will turn on the JSBCAUTH bit > * Product application code (psw key 8 problem state not-apf > authorized) will issue the SVC or PC to turn on JSCBAUTH bit > * After control returns from SVC or PC routine the application program > then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH > bit is on this does not ABEND with S047 - MODESET works. > * Application code will do "authorized stuff" > * Application will invoke the SVC or PC routine to turn off the > JSBCAUTH bit > > By dynamically turning on the JSCBAUTH bit allows the application to > dynamically elevate its z/OS authority (ability to MODESET) which it > would not normally be allowed to do. Disallowing this type of dynamic > elevation of z/OS authority would make this kind of code logic unusable. > It would force those that use this technique to adopt a different, more > secure approach. > > > On 5/31/2019 12:21 PM, Seymour J Metz wrote: > >> The security code path can be modified (if it is non-rent), frontended > by using content supervision functions (ex - task lib), or bypassed. > > Sure, a user can front end parts of the application, he won't have > access to the production data. Of course, if installation management lets > everybody and his buddy alter the production JCL, then all bets are off, > but then the crackers don't need to front end the application. > > > >>* I don't know who Schiller is. Can you clarify? Thanks. > > https://en.wikipedia.org/wiki/Friedrich_Schiller > > https://en.wikipedia.org/wiki/The_Maid_of_Orleans_(play) > > > >>* As an example - The platform could make a new integrity rule such > >> as: Only SVC 107 can turn on JSCBAUTH bit. > > Since when does MODESET turn on the JSCBAUTH bit? Just how do you > propose that IBM prevent key zero code from setting it? Why do think that > turning on JSCBAUTH lets key zero code do anything that it couldn't do > anyways? If the installation doesn't control what goes into its authorized > libraries then the vulnerability is in management, not in the platform. > > > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List on > behalf of Jesse 1 Robinson > > Sent: Thursday, May 30, 2019 5:48 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > > > It must be Friday somewhere. I put 'against stupidity' into Google. > Schiller's exact quote popped up first. Just sayin'. > > > > . > > . > > 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 Ray Overby > > Sent: Thursday, May 30, 2019 11:45 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor > Eddolls > > > > In response to "Please note that an unprivileged application can still > have a dangerous back door that compromises, e.g., privacy, by giving a > user authorized to access the application access more data than he is > authorized to see." > > > > As a developer of security interfaces for applications: It is extremely > difficult to design an unprivileged application security interface in code > that runs in PSW Key 8 problem state not apf-authorized. The security code > path can be modified (if it is non-rent), frontended by using content > supervision functions (ex - task lib), or bypassed. In addition, > application stor
Re: Just how secure are mainframes? | Trevor Eddolls
In response to "Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that IBM prevent key zero code from setting it? Why do think that turning on JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the installation doesn't control what goes into its authorized libraries then the vulnerability is in management, not in the platform." You are correct - MODESET does not set JSBCAUTH. What I meant to say is: Some of the vulnerabilities I have discovered in the wild will do the following: * As part of a APF authorized product there is a SVC or PC routine that when called will turn on the JSBCAUTH bit * Product application code (psw key 8 problem state not-apf authorized) will issue the SVC or PC to turn on JSCBAUTH bit * After control returns from SVC or PC routine the application program then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH bit is on this does not ABEND with S047 - MODESET works. * Application code will do "authorized stuff" * Application will invoke the SVC or PC routine to turn off the JSBCAUTH bit By dynamically turning on the JSCBAUTH bit allows the application to dynamically elevate its z/OS authority (ability to MODESET) which it would not normally be allowed to do. Disallowing this type of dynamic elevation of z/OS authority would make this kind of code logic unusable. It would force those that use this technique to adopt a different, more secure approach. On 5/31/2019 12:21 PM, Seymour J Metz wrote: The security code path can be modified (if it is non-rent), frontended by using content supervision functions (ex - task lib), or bypassed. Sure, a user can front end parts of the application, he won't have access to the production data. Of course, if installation management lets everybody and his buddy alter the production JCL, then all bets are off, but then the crackers don't need to front end the application. * I don't know who Schiller is. Can you clarify? Thanks. https://en.wikipedia.org/wiki/Friedrich_Schiller https://en.wikipedia.org/wiki/The_Maid_of_Orleans_(play) * As an example - The platform could make a new integrity rule such as: Only SVC 107 can turn on JSCBAUTH bit. Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that IBM prevent key zero code from setting it? Why do think that turning on JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the installation doesn't control what goes into its authorized libraries then the vulnerability is in management, not in the platform. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, May 30, 2019 5:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls It must be Friday somewhere. I put 'against stupidity' into Google. Schiller's exact quote popped up first. Just sayin'. . . 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 Ray Overby Sent: Thursday, May 30, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see." As a developer of security interfaces for applications: It is extremely difficult to design an unprivileged application security interface in code that runs in PSW Key 8 problem state not apf-authorized. The security code path can be modified (if it is non-rent), frontended by using content supervision functions (ex - task lib), or bypassed. In addition, application storage areas + ESM (external security manager) credentials cannot be in key 8 storage as the application code could accidentally or maliciously modify them. A properly designed z/OS application would have separate application and system level programs and memory objects. These programs would be invoked differently (ex - EXEC PGM= vs a SVC or PC routine). The application code would call the system level programs whenever an application function needs to be performed that requires security checks. In this way the system level code + memory objects they reference cannot be accidentally or maliciously compromised by the application code or other programs running on the platform. So called unprivileged application security code is really just application code. Important (really). But I do not like calling it security code as it does not meet the due diligence required for syste
Re: Just how secure are mainframes? | Trevor Eddolls
> The security code path can be modified (if it is non-rent), frontended by > using content supervision functions (ex - task lib), or bypassed. Sure, a user can front end parts of the application, he won't have access to the production data. Of course, if installation management lets everybody and his buddy alter the production JCL, then all bets are off, but then the crackers don't need to front end the application. > * I don't know who Schiller is. Can you clarify? Thanks. https://en.wikipedia.org/wiki/Friedrich_Schiller https://en.wikipedia.org/wiki/The_Maid_of_Orleans_(play) > * As an example - The platform could make a new integrity rule such >as: Only SVC 107 can turn on JSCBAUTH bit. Since when does MODESET turn on the JSCBAUTH bit? Just how do you propose that IBM prevent key zero code from setting it? Why do think that turning on JSCBAUTH lets key zero code do anything that it couldn't do anyways? If the installation doesn't control what goes into its authorized libraries then the vulnerability is in management, not in the platform. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, May 30, 2019 5:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls It must be Friday somewhere. I put 'against stupidity' into Google. Schiller's exact quote popped up first. Just sayin'. . . 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 Ray Overby Sent: Thursday, May 30, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see." As a developer of security interfaces for applications: It is extremely difficult to design an unprivileged application security interface in code that runs in PSW Key 8 problem state not apf-authorized. The security code path can be modified (if it is non-rent), frontended by using content supervision functions (ex - task lib), or bypassed. In addition, application storage areas + ESM (external security manager) credentials cannot be in key 8 storage as the application code could accidentally or maliciously modify them. A properly designed z/OS application would have separate application and system level programs and memory objects. These programs would be invoked differently (ex - EXEC PGM= vs a SVC or PC routine). The application code would call the system level programs whenever an application function needs to be performed that requires security checks. In this way the system level code + memory objects they reference cannot be accidentally or maliciously compromised by the application code or other programs running on the platform. So called unprivileged application security code is really just application code. Important (really). But I do not like calling it security code as it does not meet the due diligence required for system level security code. Calling application code "Unprivileged application security code" leads people to assume that the code has integrity and therefore is secure. In most cases, this is not true. It spreads a false sense of security. In response to "It can if you don't install the broken application." * Must of the code vulnerabilities I find are zero day vulnerabilities. This means there is no fix. If there is no fix then it is almost 100% certain that the client installing and/or running the product would have no idea that they are installing/running a back door on their system. * Before you install a product (how often does that happen these days?) do you ensure that all maintenance is applied or just hipers? What about integrity fix's? You probably have a different answer depending upon which vendor it is In response to "To quote Schiller, "Against stupidity the gods themselves contend in vain." The OS can prevent am unauthorized application from accessing unauthorized data or elevating its privileges; it cannot prevent the application from violating its own specifications. The OS also cannot protect against malicious modifications; it's a management responsibility to vet personnel and 3rd party providing OS changes and other privileged code." * I don't know who Schiller is. Can you clarify? Thanks. * As an example - The platform could make a new integrity rule such as: Only SVC 107 can turn on JSCBAUTH
Re: Just how secure are mainframes? | Trevor Eddolls
It must be Friday somewhere. I put 'against stupidity' into Google. Schiller's exact quote popped up first. Just sayin'. . . 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 Ray Overby Sent: Thursday, May 30, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see." As a developer of security interfaces for applications: It is extremely difficult to design an unprivileged application security interface in code that runs in PSW Key 8 problem state not apf-authorized. The security code path can be modified (if it is non-rent), frontended by using content supervision functions (ex - task lib), or bypassed. In addition, application storage areas + ESM (external security manager) credentials cannot be in key 8 storage as the application code could accidentally or maliciously modify them. A properly designed z/OS application would have separate application and system level programs and memory objects. These programs would be invoked differently (ex - EXEC PGM= vs a SVC or PC routine). The application code would call the system level programs whenever an application function needs to be performed that requires security checks. In this way the system level code + memory objects they reference cannot be accidentally or maliciously compromised by the application code or other programs running on the platform. So called unprivileged application security code is really just application code. Important (really). But I do not like calling it security code as it does not meet the due diligence required for system level security code. Calling application code "Unprivileged application security code" leads people to assume that the code has integrity and therefore is secure. In most cases, this is not true. It spreads a false sense of security. In response to "It can if you don't install the broken application." * Must of the code vulnerabilities I find are zero day vulnerabilities. This means there is no fix. If there is no fix then it is almost 100% certain that the client installing and/or running the product would have no idea that they are installing/running a back door on their system. * Before you install a product (how often does that happen these days?) do you ensure that all maintenance is applied or just hipers? What about integrity fix's? You probably have a different answer depending upon which vendor it is In response to "To quote Schiller, "Against stupidity the gods themselves contend in vain." The OS can prevent am unauthorized application from accessing unauthorized data or elevating its privileges; it cannot prevent the application from violating its own specifications. The OS also cannot protect against malicious modifications; it's a management responsibility to vet personnel and 3rd party providing OS changes and other privileged code." * I don't know who Schiller is. Can you clarify? Thanks. * As an example - The platform could make a new integrity rule such as: Only SVC 107 can turn on JSCBAUTH bit. Any other SVC or any PC routine that does it will abend with S047-98 (yes, I just created a new abend code for integrity - Byte me!). This would render useless most of the currently implemented "magic SVC or PC routines" that turn on JSCBAUTH bit that are running in the wild today (FYI - this is another sub-category of a TRAP DOOR vulnerability). There are ways to get around this (several come to mind as I write this) however I would ague that a change like this would benefit all users of the platform. The same business arguments that were used to eliminate Key 8 common storage usage could be used for this change. With similar benefits. On 5/30/2019 10:28 AM, Seymour J Metz wrote: >> Does it really matter if an application vs z/OS has a trap door >> vulnerability? > Not if you don't care about security. If you care then you must investigate > both. Please note that an unprivileged application can still have a dangerous > back door that compromises, e.g., privacy, by giving a user authorized to > access the application access more data than he is authorized to see. > >> In either case z/OS and the ESM's cannot function properly when the >> TRAP DOOR vulnerability is exploited. > It can if you don't install the broken application. > >> Shouldn't z/OS be able to protec
Re: Just how secure are mainframes? | Trevor Eddolls
In securing Mainframe: One thing I've noticed over the years is how a Company will "hide" their Mainframe hardware. The Hardware for me now is in a unmarked Building that looks like a bunker (I'm told). Pretty bad that the location is in my town, however the address is NOT circulated. The first installation that I worked at, it was well known where the data center was. It was no issue to walk into Operations and tour new equipment or talk to operators. Now, forget it. Thanks, Tom Savor -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Schuffenhauer, Mark Sent: Wednesday, May 29, 2019 2:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls ⚠ EXTERNAL MESSAGE – Think Before You Click My sales favorite was knowing key functionality is vaporware, talking up everything the software would do some day. Then being horrified when you realize the 'decision makers' are eating it up. None of them ends up in hell when the product doesn't work and the functionality delivery date keeps getting pushed forward... but, I got to work with a 3745 until 2009. Security is no good without PEN testing and auditing from the Security Technical Implementation Guide (STIG) documents. If you haven't crossed your eyes and dotted your teas wait, reverse that. Your odds of solid security can be greatly decreased. No security by obscurity. EBCDIC is not a method of encryption. Stop people from using stupid passwords. Ideally daily ID's have no elevated access, any elevated id must be checked out, activated, with a new password on each use. I realize that would be messy, but if you have better password security(pass phrases, excluded words (months of the year, or seasons) or MFA going, never mind. This isn't the paragraph you're looking for... -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ray Overby Sent: Wednesday, May 29, 2019 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR code vulnerability pierces the veil of integrity and can be used to compromise the mainframe. Is this a platform weakness? I think so. The platform relies on all code it runs adhering to certain rules. z/OS could be changed to better check and enforce those rules. Would you say that the elimination of User Key Common storage is an example of a z/OS change to address a mainframe platform weakness? I think so. An interesting observation. Thanks. On 5/29/2019 5:25 AM, R.S. wrote: > That's classical FUD. > Frightening people. > "if an exploit", "if job reads you RACF db", "unintended consequences". > What exactly hacking scenario can provide RACF db to the hacker? > Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user > attribute, even UPDATE to RACF db. But it's problem of people. > Mistakes, lack of time, lack of control, lack of skills. Not a > platform weakness. > > It's typical that assurance/lock/gun salesmen tend to talk about > risks, threats and dangers. They create a vision. > My English is poor, but I can observe it for two of debaters here. > It's visible. I don't like social engineering. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN DISCLAIMER: This email and any attachments may contain confidential information that is intended solely for use by the intended recipient(s). If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the communication. If you received this email in error, please contact the sender by reply email and immediately delete the communication. -- 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: Just how secure are mainframes? | Trevor Eddolls
well, here's my embarrassed face :( I was led to believe qradar was a tool to review security issues also, as you can tell I don't know the product well. I didn't want to dig into all the, already mentioned security issues with APF, RACF SPECIAL, UID 0,etc, but I know most places I worked for had standard practices and reporting facilities to review and correct these holes. one standard we use now to logon is MFA, badge, with a chip, pin # and our ID and password, even for on-call and working from home. I hear a rumor we will be moving to a MFA with 3 levels of security... UGH! . Carmen Vitullo - Original Message - From: "ITschak Mugzach" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, May 29, 2019 8:01:48 AM Subject: Re: Just how secure are mainframes? | Trevor Eddolls Carmen, t think you are mixing event audit (siem product like qradar) with status which was the subject of this thread. Siem is good, but my experience create lot of false positive alerts. ITschak בתאריך יום ד׳, 29 במאי 2019, 15:54, מאת Carmen Vitullo : > That's one response I can agree with ! > > > I didn't want to drag myself into this, I also have been working for > outsourcers, who's customers were very large banks, insurance companies, > worked for a very large defense contractor, state Government, and now back > in one of the largest health care insurance companies in the US, and I know > there are all security standards for each, some follow the same base > security standards and some have a higher level of standards , they are not > all perfect. one thing I've not head is someone quoting any standards by > name, for security and auditing, HITRUST is one of our standard, some > standards we adopted over the years because we learned where our security > holes where. I think we can argue till the cows come home about who's more > secure, I know by fact, our Micro team is up very early in the AM 3-4 times > a week applying security patches by the hundreds in the windows world, > maybe I'm a little lax but I don't see us doing this in the Z environment > so often. > we use tools to monitor and report TSS security issues, a standard tool > called QRADAR, it also is not perfect, but it allows the security team some > insight as to what security issues we all have in the enterprise, Winders, > AIX, Linux and Z. > > > > Carmen Vitullo > > - Original Message - > > From: "ITschak Mugzach" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Wednesday, May 29, 2019 7:26:10 AM > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > Where is the list moderator when we need him/her. Some people here > completely lost their manners. > > ITschak > > בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu>: > > > Nah, I’ll go back to lurking. I forgot many of you already know > everything. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. < > > 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > > > > Questioning the integrity of a man with his credentials and background > in > > mainframe security for over 30+ years? Who the hell are you that I > should > > even listen to one more word from you? Better to be a fool and know it > than > > open your mouth and remove all shadow of doubt. > > > > Bill, if you can overcome your arrogance, you should probably apologize. > > If not, take your trolling to some other place. > > > > One final comment: If you had consulted on a "real life event" would you > > give explicit details of who, what, when and where to some stranger? > > Especially one who has questioned the comments of everyone attempting to > > respond on this thread? > > > > I'll entertain one more response from you before I place you in the > > virtual Anton Britz lookalike folder. Make it a good one. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of Bill Johnson > > Sent: Tuesday, May 28, 2019 8:26 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > > > I posted 3-4 links from varying sources all saying the same thing. > Banks, > > insurance, big retail all use the mainframe for approximately 3 major > > reasons, one of which is security. Then Ray wants to show me some > > controlled experiment that is nothing but a lab event that he can’t show > to > >
Re: Just how secure are mainframes? | Trevor Eddolls
Carmen, t think you are mixing event audit (siem product like qradar) with status which was the subject of this thread. Siem is good, but my experience create lot of false positive alerts. ITschak בתאריך יום ד׳, 29 במאי 2019, 15:54, מאת Carmen Vitullo : > That's one response I can agree with ! > > > I didn't want to drag myself into this, I also have been working for > outsourcers, who's customers were very large banks, insurance companies, > worked for a very large defense contractor, state Government, and now back > in one of the largest health care insurance companies in the US, and I know > there are all security standards for each, some follow the same base > security standards and some have a higher level of standards , they are not > all perfect. one thing I've not head is someone quoting any standards by > name, for security and auditing, HITRUST is one of our standard, some > standards we adopted over the years because we learned where our security > holes where. I think we can argue till the cows come home about who's more > secure, I know by fact, our Micro team is up very early in the AM 3-4 times > a week applying security patches by the hundreds in the windows world, > maybe I'm a little lax but I don't see us doing this in the Z environment > so often. > we use tools to monitor and report TSS security issues, a standard tool > called QRADAR, it also is not perfect, but it allows the security team some > insight as to what security issues we all have in the enterprise, Winders, > AIX, Linux and Z. > > > > Carmen Vitullo > > - Original Message - > > From: "ITschak Mugzach" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Wednesday, May 29, 2019 7:26:10 AM > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > Where is the list moderator when we need him/her. Some people here > completely lost their manners. > > ITschak > > בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu>: > > > Nah, I’ll go back to lurking. I forgot many of you already know > everything. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. < > > 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > > > > Questioning the integrity of a man with his credentials and background > in > > mainframe security for over 30+ years? Who the hell are you that I > should > > even listen to one more word from you? Better to be a fool and know it > than > > open your mouth and remove all shadow of doubt. > > > > Bill, if you can overcome your arrogance, you should probably apologize. > > If not, take your trolling to some other place. > > > > One final comment: If you had consulted on a "real life event" would you > > give explicit details of who, what, when and where to some stranger? > > Especially one who has questioned the comments of everyone attempting to > > respond on this thread? > > > > I'll entertain one more response from you before I place you in the > > virtual Anton Britz lookalike folder. Make it a good one. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of Bill Johnson > > Sent: Tuesday, May 28, 2019 8:26 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > > > I posted 3-4 links from varying sources all saying the same thing. > Banks, > > insurance, big retail all use the mainframe for approximately 3 major > > reasons, one of which is security. Then Ray wants to show me some > > controlled experiment that is nothing but a lab event that he can’t show > to > > have ever occurred in real life. No thanks. > > > > > > Sent from Yahoo Mail for iPhone > > > > > > On Tuesday, May 28, 2019, 6:22 PM, zMan wrote: > > > > So...you make statements and don't back them up, and when offered > > coutner-examples, refuse to view them? > > > > Plonk. > > > > On Tue, May 28, 2019 at 1:30 PM Bill Johnson < > > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Demos remind me of this joke. > > > http://www.jokes.net/heavenandhell.htm > > > I’ve seen my share of demos that make claims or promises that simply > > never > > > occur. > > > Thanks Ray, I’ll pass. > > > > > > > -- > > For IBM-MAIN subsc
Re: Just how secure are mainframes? | Trevor Eddolls
That's one response I can agree with ! I didn't want to drag myself into this, I also have been working for outsourcers, who's customers were very large banks, insurance companies, worked for a very large defense contractor, state Government, and now back in one of the largest health care insurance companies in the US, and I know there are all security standards for each, some follow the same base security standards and some have a higher level of standards , they are not all perfect. one thing I've not head is someone quoting any standards by name, for security and auditing, HITRUST is one of our standard, some standards we adopted over the years because we learned where our security holes where. I think we can argue till the cows come home about who's more secure, I know by fact, our Micro team is up very early in the AM 3-4 times a week applying security patches by the hundreds in the windows world, maybe I'm a little lax but I don't see us doing this in the Z environment so often. we use tools to monitor and report TSS security issues, a standard tool called QRADAR, it also is not perfect, but it allows the security team some insight as to what security issues we all have in the enterprise, Winders, AIX, Linux and Z. Carmen Vitullo - Original Message - From: "ITschak Mugzach" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, May 29, 2019 7:26:10 AM Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls Where is the list moderator when we need him/her. Some people here completely lost their manners. ITschak בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu>: > Nah, I’ll go back to lurking. I forgot many of you already know everything. > > > Sent from Yahoo Mail for iPhone > > > On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. < > 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > > Questioning the integrity of a man with his credentials and background in > mainframe security for over 30+ years? Who the hell are you that I should > even listen to one more word from you? Better to be a fool and know it than > open your mouth and remove all shadow of doubt. > > Bill, if you can overcome your arrogance, you should probably apologize. > If not, take your trolling to some other place. > > One final comment: If you had consulted on a "real life event" would you > give explicit details of who, what, when and where to some stranger? > Especially one who has questioned the comments of everyone attempting to > respond on this thread? > > I'll entertain one more response from you before I place you in the > virtual Anton Britz lookalike folder. Make it a good one. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Tuesday, May 28, 2019 8:26 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > I posted 3-4 links from varying sources all saying the same thing. Banks, > insurance, big retail all use the mainframe for approximately 3 major > reasons, one of which is security. Then Ray wants to show me some > controlled experiment that is nothing but a lab event that he can’t show to > have ever occurred in real life. No thanks. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, May 28, 2019, 6:22 PM, zMan wrote: > > So...you make statements and don't back them up, and when offered > coutner-examples, refuse to view them? > > Plonk. > > On Tue, May 28, 2019 at 1:30 PM Bill Johnson < > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > > > Demos remind me of this joke. > > http://www.jokes.net/heavenandhell.htm > > I’ve seen my share of demos that make claims or promises that simply > never > > occur. > > Thanks Ray, I’ll pass. > > > > -- > 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 /
Re: Just how secure are mainframes? | Trevor Eddolls
> There are tools to enforce user authentication. How is that relevant to making selected files available to the general public? You can't authenticate someone you've never heard of. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, May 28, 2019 5:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls On Tue, 28 May 2019 20:41:50 +, Seymour J Metz wrote: >What if you have a business need to make files available to the general >public? Do you really believe that the web infrastructure is any more secure >than FTP, or even as secure? > There are tools to enforce user authentication. E-Commerce relies on these. Of course, they are only secure as the care taken in deployment. RACF profiles can help enormously (UACC=READ for HTTPD/FTPD). Does CGIWrap help? http://secure-web.cisco.com/1_X3m_rKmNkg9Z_swcraQ6GVLfsGW2xWgDRf2MYlBQZpEUAWG1qOZLDLzI2dI7swz32GFDWl7BOgRcb3Qwc3_7cvPV2b3Bf833bujON9NDtdOXr8FWdLBvn3ubxNl8u8fF7UOGjuGMLyZ5_wDrt_Uep2wnYTZi2YO8LzTc_S8up228Dr7htVDKwQWPKyEMRKQeE8JINJoPCMh5G6w_YP2MnMlZ1MkbzOC9eKah9gm19cxWZOV4O6Is-YvDfubffvEibizdJM_KuyOzZWcASigYhHOtQKUeBgF_fqT9xyRtM-Ly51WV9U1sC7u3akrRB9_hDtXugxWYe4k6ZVwlNvxNfGAlH_g0yvDUj8oDjWbV3u2Rxn14yxzZbU2rNQfaOA3ZLkIjNSS6RglRv0gBqXdWpMdnxPY3ZAxBp7rA5ybrzbamWMW9Idfsfcn3QFreyV4/http%3A%2F%2Fcgiwrap.sourceforge.net%2Fintro.html -- gil -- 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: Just how secure are mainframes? | Trevor Eddolls
On Tue, 28 May 2019 20:41:50 +, Seymour J Metz wrote: >What if you have a business need to make files available to the general >public? Do you really believe that the web infrastructure is any more secure >than FTP, or even as secure? > There are tools to enforce user authentication. E-Commerce relies on these. Of course, they are only secure as the care taken in deployment. RACF profiles can help enormously (UACC=READ for HTTPD/FTPD). Does CGIWrap help? http://cgiwrap.sourceforge.net/intro.html -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
