*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. <000001c91f408b9e-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 <cfmt...@uniserve.com> wrote: [Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main 00000047540adefe-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 <sme...@gmu.edu> 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 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
