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 <cfmt...@uniserve.com> wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 00000047540adefe-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 <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
