Timothy, While I don't disagree with you, I think that most people here feel that these topics are systemic issues with any platform. Storing unencrypted (or even encrypted) userids and passwords in datasets or files that are not highly restricted is a major liability. I feel that it is disingenuous and unrealistic to say that a mainframe is antiquated or obsolete because of these issues. These are just security 101 topics that are valid for every platform.
Thank you, Brian Chapman On Thu, Aug 15, 2019 at 12:26 AM Timothy Sipples <sipp...@sg.ibm.com> wrote: > Let's quote the author directly, OK? I'm going to quote the whole second > section since context is important: > > "2. Data Left Behind > > "Because mainframes were once typically set-up-and-forget systems, they > often contain sensitive data files that should have been deleted after the > deployment phase ended. Certain data should not be written to a space that > just any user can access. > > > "We had one mainframe hacker who logged into the mainframe as an > unprivileged user and immediately saw a highly sensitive file that > contained information she could have used to compromise high-privileged > users in the company’s environment. Files, such as lists of usernames and > passwords and confidential client information, should not remain on the > mainframe, where they are exposed to any type of user who gains physical or > remote access." > > > I don't think this is a particularly well written (or well edited? editors > can sometimes do damage) piece of text -- let me just say that up front. > However, in context, it's not awful. Let's work through this together.... > > > "Because mainframes were once typically set-up-and-forget systems...." > > > That's not the first description that comes to mind of classic mainframes > running MVS, for example. However, that is an excellent description of IBM > AS/400s, and I have seen more than a few references to AS/400s (and IBM i > machines) as "mainframes." That said, the first sentence is my least > favorite. > > > Sentence #2 in this section is quite important for context. > > > "Files, such as lists of usernames and passwords and confidential client > information, should not remain on the mainframe, where they are exposed to > any type of user who gains physical or remote access." > > > I don't think we should automatically blame the author for a stray comma. > Let me oh-so-slightly adjust this sentence, and I'm going to add three > words just to emphasize the problem with that comma: > > > "Files, such as lists of usernames and passwords and confidential client > information, should not remain on the mainframe or anywhere else where they > are exposed to any type of user who gains physical or remote access." > > > It's a very, very reasonable interpretation in context that that's what the > author meant, but the comma, in particular, wasn't at all helpful. No, that > comma certainly shouldn't be there, but it's a comma, and editors (and > sometimes authors) unfortunately make punctuation mistakes. > > > Has anyone who doesn't like this article bothered to contact the author, or > at least try, to suggest improvements? If not, why not? > > > -------------------------------------------------------------------------------------------------------- > Timothy Sipples > IT Architect Executive, Industry Solutions, IBM Z & LinuxONE > > -------------------------------------------------------------------------------------------------------- > > E-Mail: sipp...@sg.ibm.com > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
