I didn't offer anything. Read the thread from begining. I was the first to confirm the PEOPLE is the main issue.
Yes, I don't think clients buy mainframes because they are more secure, i don't know if there are new clients for mainframes in the last few years. Most, if not all, mainframe clients i know (many in three continents) had the computing needs and was able to pay for them, years before any alternative even exist. For good or bad, this is where they put their money and i show many others that decided that their money can buy better. I don't think they did a right decision, but they never asked me... And... I never use FAD. Security is the provider responsibility. They perform under laws, acts, regulations, auditors, what ever. I can help make identifying risks quicker, i am not managing their client's money, information or supplied resources like energy, water or food. If they do better without my and other vendors tools or services, that is great. ITschak ITschak בתאריך יום ד׳, 29 במאי 2019, 13:25, מאת R.S. < [email protected]>: > 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. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > > W dniu 2019-05-28 o 20:41, Ray Overby pisze: > > Peter - That is a good question. I think there may be several ways to > > explain this: > > > > * When I explain code vulnerabilities to z/OS assembler developers I > > tell them: It is not good enough for the code to work as designed - > > it must have no unintended consequences.If an installation > > implements FTP JES support in such a way that it allows both > > legitimate users (ex - IBM z/OS and CICS Explorer Eclipse base > > products) and illegitimate users to use it then there may be a > > vulnerability in the FTP JES implementation. For example, if an > > external user could run a job submitted via FTP JES to list the > > payroll file or the ESM database but that is not the installations > > intended use of the FTP JES support then I would suggest that this > > would be a vulnerability. > > * If an exploit was developed to exfiltrate the payroll file or the > > ESM database and FTP JES was part of the path the exploit used then > > one should review the FTP JES implementation to see how controls can > > be tightened to eliminate or reduce the "unintended consequences". > > You would of course also look at the other parts of the exploit and > > do the same. > > > > Which option you use is usually dictated by whether you are looking > > for problems that may not have occurred yet (1st option) or you are > > trying to figure out what happened (2nd option). > > > > The use of FTP JES option is not by itself a vulnerability. But it can > > be if not properly configured (including the ESM controls). It is also > > something the other platforms understand and will take advantage of if > > not properly controlled for unintended consequences. > > > > /IOW, how is FTP JES submission any different from TSO SUBMIT? > > /Functionally, they both do the same thing. What I think is different > > is that FTP JES may be done from environments outside the scope and > > control of a z/OS system. Those environments may not be as secure as > > z/OS. > > // > > > > > > On 5/28/2019 12:46 PM, Farley, Peter x23353 wrote: > >> Ray, > >> > >> PMFJI here, but as a regular application programmer (not a sysprog) I > >> do not understand how the FTP JES option allowed is a configuration > >> vulnerability. > >> > >> Isn't the FTP JES option one of the ways that the IBM z/OS and CICS > >> Explorer Eclipse-based products (and maybe other ISV Eclipse GUI's) > >> provide to let you submit and review the results of compile and > >> program test and bundle transmission jobs? If my FTP submitted jobs > >> must have my userid+1 as the job name and my userid access is > >> properly controlled by the ESM, how is that vulnerable? > >> > >> IOW, how is FTP JES submission any different from TSO SUBMIT? > >> > >> Peter > > >> [...] > > ====================================================================== > > 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: [email protected]. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, 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: [email protected]. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 0000025237, 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
