At the IRS we are given courses in UNAX ( unauthorized access) for those who have access to production data to be very careful
Making a mistake can lead to anywhere from loss of job to possible Jail > On Mar 26, 2021, at 1:47 PM, Farley, Peter x23353 > <0000031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > Jeremy, > > I have to disagree with you here about access to read (not modify) production > data by application developers. Full read access to production data > (especially when the quantities are very large and cannot easily be copied to > "test" disk pools which are usually much smaller than production) is a > critical problem solving and research tool. > > I deal with very large quantities of "production" data every day for both > client issue resolution and business function enhancement research. Simple > examples are "How many widgets does client xyz process in a day? In a week? > In a month? And what application characteristics did we apply to the client > processing of that widget (or ones of similar type abc)?". > > I do understand that possible malfeasance by bad-actor "insiders" like > application programmers is considered a business risk, but the solution is > not to prevent normal, every-day read access to those insiders, but to limit > the actual PII data available to them via masked files. > > In the case that even masking files is difficult or impossible due to the > inherent vast volume of the data, the only reasonable real-world solution is > "trust but verify" your employee's activities. > > Denying access by programmers to production data is a disaster all by itself > for any kind of reasonable and necessary client issue resolution time scale > and for reasonable business function enhancement research timelines. > > I do agree that PII data should usually be masked for application programmer > access if at all possible (it certainly is where I work), but in the Mr. > Reichman's case just about the entire data contents is PII. "Trust but > verify" is the only reasonable business solution in his case, absent vast > duplication of huge quantities of data for masked copies. And remember our > tax dollars have to pay for that duplication. > > Various implementations of so-called "break glass" procedures to assign > special temporary system identifiers for programmers to gain access to > un-masked production data frequently ignores the fact that the programmer > also needs access to all their non-production tools and libraries while using > the production data. I have never seen such a process that actually works > when time is of the essence (e.g., a serious production-stopping issue). > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Jeremy Nicoll > Sent: Friday, March 26, 2021 11:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dataset contention > > <Snipped> >> if it’s >> corrupted I can run it again it won’t happen and like I said it’s not >> production if it was that would change things > > I really don't understand how you can be trawling through vast amounts of tax > (IIRC) data, and it not be production. I mean, it's live datasets, is it not? > > Surely you wouldn't have access to that data unless there was a proper > authorised use-case. > > Re-running jobs just wastes system resources. > > Does nobody supervise what you and your colleagues do? > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > > ---------------------------------------------------------------------- > 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
