subject:"Fwd\: Just how secure are mainframes\? \| Trevor Eddolls"

n List  on behalf of Ray 
Overby 
Sent: Thursday, May 30, 2019 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "An application with a trap door is an application
vulnerability. If there is a trap door in z/OS itself then that's a
platform vulnerability."

Does it really matter if an application vs z/OS has a trap door
vulnerability? In either case z/OS and the ESM's cannot function
properly when the TRAP DOOR vulnerability is exploited. Shouldn't z/OS
be able to protect itself from accidental and/or malicious
vulnerabilities? Isn't that what a platform is supposed to do? Isn't
that a requirement of a secure system?

Every program in z/OS has certain rules of the road it must abide by.
System level programs (PSW Key 0-7, Supervisor State, APF authorized)
regardless of whether they are in z/OS or an application have additional
rules they must adhere to (i.e. - they must not violate the integrity of
z/OS). These rules of the road are the responsibility of and dictated by
the platform. Integrity is a platform issue.

One of the reason's the mainframe is the most secure-able platform is at
least partially based on integrity. Integrity as implemented by the
platform is why security is possible. Without platform integrity
security is not possible. So all code (z/OS and application) that
operates at a system level (i.e. - PSW Key 0-7, Supervisor state, APF
authorized) must not violate the integrity rules. Failure of a single
program regardless of whether it is part of z/OS or an application will
allow a hacker to compromise that system and all data on it.

In response to "I'd be willing to bet a substantial amount that the
majority of penetrations in z/OS are application, configuration,
personnel and process vulnerabilities rather than z/OS vulnerabilities."

In terms of numbers of vulnerabilities there are fewer code based
vulnerabilities (TRAP DOOR is one example of a code based
vulnerabilities - there are others) vs configuration based
vulnerabilities. I would point out that a hacker only needs a single
TRAP DOOR  vulnerability to compromise the platform regardless of how
the platform is configured. So fewer code based vulnerabilities does not
help. All code based vulnerabilities have to be removed from the system
in order to secure the platform.

On 5/29/2019 2:57 PM, Seymour J Metz wrote:

   A single TRAP DOOR code vulnerability pierces the veil of integrity and can 
be used
to compromise the mainframe. Is this a platform weakness?

An application with a trap door is an application vulnerability. If there is a 
trap door in z/OS itself then that's a platform vulnerability. I'd be willing 
to bet a substantial amount that the majority of penetrations in z/OS are 
application, configuration, personnel and process vulnerabilities rather than 
z/OS vulnerabilities.

Would you say that the elimination of User Key Common storage is an
example of a z/OS change to address a mainframe platform weakness

Partially.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Wednesday, May 29, 2019 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: The mainframe platform, z/OS, and
ESM's all rely on integrity to function. A single TRAP DOOR code
vulnerability pierces the veil of integrity and can be used to
compromise the mainframe. Is this a platform weakness? I think so. The
platform relies on all code it runs adhering to certain rules. z/OS
could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an
example of a z/OS change to address a mainframe platform weakness? I
think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Tom Brennan


Thanks!

On 5/30/2019 9:20 AM, Ray Overby wrote:
ESM - External Security Manager. I use ESM when I am talking about ACF2, 
RACF, and TSS.



On 5/30/2019 10:20 AM, Tom Brennan wrote:
I've seen the acronym ESM a few times in this thread.  I'll assume 
that means "Enterprise Security Management", and I'll guess it refers 
to security processes (not RACF), such as assigning userid's, making 
sure people have just the access they need, periodic audits, etc.


Am I even close?

On 5/30/2019 4:28 AM, Ray Overby wrote:
In response to "An application with a trap door is an application 
vulnerability. If there is a trap door in z/OS itself then that's a 
platform vulnerability."


Does it really matter if an application vs z/OS has a trap door 
vulnerability? In either case z/OS and the ESM's cannot function ...


--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

ESM - External Security Manager. I use ESM when I am talking about ACF2, 
RACF, and TSS.



On 5/30/2019 10:20 AM, Tom Brennan wrote:
I've seen the acronym ESM a few times in this thread.  I'll assume 
that means "Enterprise Security Management", and I'll guess it refers 
to security processes (not RACF), such as assigning userid's, making 
sure people have just the access they need, periodic audits, etc.


Am I even close?

On 5/30/2019 4:28 AM, Ray Overby wrote:
In response to "An application with a trap door is an application 
vulnerability. If there is a trap door in z/OS itself then that's a 
platform vulnerability."


Does it really matter if an application vs z/OS has a trap door 
vulnerability? In either case z/OS and the ESM's cannot function ...


--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls


Yes.

On 5/30/2019 11:01 AM, Seymour J Metz wrote:

It is obvious that IBM has vulnerabilities in z/OS.

Water is wet; I've reported one such. But not all vulnerabilities are trap 
doors.

Do you know of a trap door installed by IBM?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Lou Losee 

Sent: Thursday, May 30, 2019 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Just because it has not been brought up and I think it is pertinent to this
discussion.

It is obvious that IBM has vulnerabilities in z/OS.  The existence of the
integrity APARs are proof of that.  There may not be as many as the fixes
released for Windows or Mac, but they do exist.

Lou
--
Artificial Intelligence is no match for Natural Stupidity
   - Unknown


On Thu, May 30, 2019 at 10:33 AM Seymour J Metz  wrote:


I've never seen a trap door installed by IBM. What I've seen was trap
doors installed by data center staff and trap doors in 3rd party software.
In those cases it's not the platform that is insecure but the installation.
Would you blame the lock if someone leaves their key under the doormat?

d) You know how to fix the trap door but management won't let you.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf
of R.S. 
Sent: Thursday, May 30, 2019 7:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

As Shmuel said an application with a trap door is an application
vulnerability.
Ideed, IF you know such trap door, you know z/OS vulnerability, which
proves the platform is not immune. Is it as vulnerable as Windows? No,
because it's still not binary, some systems are still more secure than
others.

Last, but not least:  assuming you know such trap door. Or even several
trap doors. What next?
a) you submitted it to IBM and they are trying to fix it.
b) despite of a) you know how to fix it by homegrown
code/configuration/procedure and you offer it as a service.
c) the trap door cannot be fixed and then your services are disputable -
you cannot help.

Of course the above *regards only the trap doors you know*, not your
services portfolio.
Besides that you can provide many valuable services regarding security,
but not platform issues, rather people mistakes, misconfigurations,
erroneous procedures, etc.
It is worth to emphasize: while z/OS is quite secure, it may be quite
complex to configure it properly. And here there is a field for Ray,
ITschak, RSM Partners, me, etc.

--
Radoslaw Skorupka
Lodz, Poland





W dniu 2019-05-29 o 17:11, Ray Overby pisze:

In response to "Mistakes, lack of time, lack of control, lack of
skills. Not a platform weakness." comment: The mainframe platform,
z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR
code vulnerability pierces the veil of integrity and can be used to
compromise the mainframe. Is this a platform weakness? I think so. The
platform relies on all code it runs adhering to certain rules. z/OS
could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an
example of a z/OS change to address a mainframe platform weakness? I
think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:

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.

==

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,
http://secure-web.cisco.com/14ILHCRRunYvlSTtGew3dxkMnoq-EQXun

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Seymour J Metz

> It is obvious that IBM has vulnerabilities in z/OS.

Water is wet; I've reported one such. But not all vulnerabilities are trap 
doors.

Do you know of a trap door installed by IBM?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Lou 
Losee 
Sent: Thursday, May 30, 2019 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Just because it has not been brought up and I think it is pertinent to this
discussion.

It is obvious that IBM has vulnerabilities in z/OS.  The existence of the
integrity APARs are proof of that.  There may not be as many as the fixes
released for Windows or Mac, but they do exist.

Lou
--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown


On Thu, May 30, 2019 at 10:33 AM Seymour J Metz  wrote:

> I've never seen a trap door installed by IBM. What I've seen was trap
> doors installed by data center staff and trap doors in 3rd party software.
> In those cases it's not the platform that is insecure but the installation.
> Would you blame the lock if someone leaves their key under the doormat?
>
> d) You know how to fix the trap door but management won't let you.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of R.S. 
> Sent: Thursday, May 30, 2019 7:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> As Shmuel said an application with a trap door is an application
> vulnerability.
> Ideed, IF you know such trap door, you know z/OS vulnerability, which
> proves the platform is not immune. Is it as vulnerable as Windows? No,
> because it's still not binary, some systems are still more secure than
> others.
>
> Last, but not least:  assuming you know such trap door. Or even several
> trap doors. What next?
> a) you submitted it to IBM and they are trying to fix it.
> b) despite of a) you know how to fix it by homegrown
> code/configuration/procedure and you offer it as a service.
> c) the trap door cannot be fixed and then your services are disputable -
> you cannot help.
>
> Of course the above *regards only the trap doors you know*, not your
> services portfolio.
> Besides that you can provide many valuable services regarding security,
> but not platform issues, rather people mistakes, misconfigurations,
> erroneous procedures, etc.
> It is worth to emphasize: while z/OS is quite secure, it may be quite
> complex to configure it properly. And here there is a field for Ray,
> ITschak, RSM Partners, me, etc.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> W dniu 2019-05-29 o 17:11, Ray Overby pisze:
> > In response to "Mistakes, lack of time, lack of control, lack of
> > skills. Not a platform weakness." comment: The mainframe platform,
> > z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR
> > code vulnerability pierces the veil of integrity and can be used to
> > compromise the mainframe. Is this a platform weakness? I think so. The
> > platform relies on all code it runs adhering to certain rules. z/OS
> > could be changed to better check and enforce those rules.
> >
> > Would you say that the elimination of User Key Common storage is an
> > example of a z/OS change to address a mainframe platform weakness? I
> > think so.
> >
> > An interesting observation. Thanks.
> >
> > On 5/29/2019 5:25 AM, R.S. wrote:
> >> 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.
>
> ==
>
> 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)

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Lou Losee

Just because it has not been brought up and I think it is pertinent to this
discussion.

It is obvious that IBM has vulnerabilities in z/OS.  The existence of the
integrity APARs are proof of that.  There may not be as many as the fixes
released for Windows or Mac, but they do exist.

Lou
--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown


On Thu, May 30, 2019 at 10:33 AM Seymour J Metz  wrote:

> I've never seen a trap door installed by IBM. What I've seen was trap
> doors installed by data center staff and trap doors in 3rd party software.
> In those cases it's not the platform that is insecure but the installation.
> Would you blame the lock if someone leaves their key under the doormat?
>
> d) You know how to fix the trap door but management won't let you.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of R.S. 
> Sent: Thursday, May 30, 2019 7:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> As Shmuel said an application with a trap door is an application
> vulnerability.
> Ideed, IF you know such trap door, you know z/OS vulnerability, which
> proves the platform is not immune. Is it as vulnerable as Windows? No,
> because it's still not binary, some systems are still more secure than
> others.
>
> Last, but not least:  assuming you know such trap door. Or even several
> trap doors. What next?
> a) you submitted it to IBM and they are trying to fix it.
> b) despite of a) you know how to fix it by homegrown
> code/configuration/procedure and you offer it as a service.
> c) the trap door cannot be fixed and then your services are disputable -
> you cannot help.
>
> Of course the above *regards only the trap doors you know*, not your
> services portfolio.
> Besides that you can provide many valuable services regarding security,
> but not platform issues, rather people mistakes, misconfigurations,
> erroneous procedures, etc.
> It is worth to emphasize: while z/OS is quite secure, it may be quite
> complex to configure it properly. And here there is a field for Ray,
> ITschak, RSM Partners, me, etc.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> W dniu 2019-05-29 o 17:11, Ray Overby pisze:
> > In response to "Mistakes, lack of time, lack of control, lack of
> > skills. Not a platform weakness." comment: The mainframe platform,
> > z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR
> > code vulnerability pierces the veil of integrity and can be used to
> > compromise the mainframe. Is this a platform weakness? I think so. The
> > platform relies on all code it runs adhering to certain rules. z/OS
> > could be changed to better check and enforce those rules.
> >
> > Would you say that the elimination of User Key Common storage is an
> > example of a z/OS change to address a mainframe platform weakness? I
> > think so.
> >
> > An interesting observation. Thanks.
> >
> > On 5/29/2019 5:25 AM, R.S. wrote:
> >> 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.
>
> ==
>
> 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,
> http://secure-web.cisco.com/14ILHCRRunYvlSTtGew3dxkMnoq-EQXunQmxen_zjQXxLP_IX-Ug58lArQAAiDC5ACZe4lMf0-jck0ghav2cqfF_LnMQM_LW30FcxGv_RtgvQgLZhcGgFKSX0F8zBNsaREU7crKD5N9qMEep08A3

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Seymour J Metz

I've never seen a trap door installed by IBM. What I've seen was trap doors 
installed by data center staff and trap doors in 3rd party software. In those 
cases it's not the platform that is insecure but the installation. Would you 
blame the lock if someone leaves their key under the doormat?

d) You know how to fix the trap door but management won't let you.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Thursday, May 30, 2019 7:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

As Shmuel said an application with a trap door is an application
vulnerability.
Ideed, IF you know such trap door, you know z/OS vulnerability, which
proves the platform is not immune. Is it as vulnerable as Windows? No,
because it's still not binary, some systems are still more secure than
others.

Last, but not least:  assuming you know such trap door. Or even several
trap doors. What next?
a) you submitted it to IBM and they are trying to fix it.
b) despite of a) you know how to fix it by homegrown
code/configuration/procedure and you offer it as a service.
c) the trap door cannot be fixed and then your services are disputable -
you cannot help.

Of course the above *regards only the trap doors you know*, not your
services portfolio.
Besides that you can provide many valuable services regarding security,
but not platform issues, rather people mistakes, misconfigurations,
erroneous procedures, etc.
It is worth to emphasize: while z/OS is quite secure, it may be quite
complex to configure it properly. And here there is a field for Ray,
ITschak, RSM Partners, me, etc.

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2019-05-29 o 17:11, Ray Overby pisze:
> In response to "Mistakes, lack of time, lack of control, lack of
> skills. Not a platform weakness." comment: The mainframe platform,
> z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR
> code vulnerability pierces the veil of integrity and can be used to
> compromise the mainframe. Is this a platform weakness? I think so. The
> platform relies on all code it runs adhering to certain rules. z/OS
> could be changed to better check and enforce those rules.
>
> Would you say that the elimination of User Key Common storage is an
> example of a z/OS change to address a mainframe platform weakness? I
> think so.
>
> An interesting observation. Thanks.
>
> On 5/29/2019 5:25 AM, R.S. wrote:
>> 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.

==

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,http://secure-web.cisco.com/14ILHCRRunYvlSTtGew3dxkMnoq-EQXunQmxen_zjQXxLP_IX-Ug58lArQAAiDC5ACZe4lMf0-jck0ghav2cqfF_LnMQM_LW30FcxGv_RtgvQgLZhcGgFKSX0F8zBNsaREU7crKD5N9qMEep08A3gQGMJb3xeCyGFXo40ow3C4kklzJKo8ceb3j4dNkhTHXRroJVJvFgw8OmxGSZLh5Cd0s4plzQ0KQOs4Xy6uxx3qpKYcs3SBxUf0fBQo3DcK2kSBE4k3ScihhcNjTJwUDXdyrULocL9bMwXrAVups_q5FzLwrUN5zsycmBegw6QssGwOBAEpAD4PJuMl7bPaecJqL_m4uu_J6gwb2aG9F4h4wvt2z8H95YdG86TQJTbDpHc/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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,

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Seymour J Metz

> Does it really matter if an application vs z/OS has a trap door vulnerability?

Not if you don't care about security. If you care then you must investigate 
both. Please note that an unprivileged application can still have a dangerous 
back door that compromises, e.g., privacy, by giving a user authorized to 
access the application access more data than he is authorized to see.

> In either case z/OS and the ESM's cannot function
> properly when the TRAP DOOR vulnerability is exploited.

It can if you don't install the broken application.

> Shouldn't z/OS be able to protect itself from accidental and/or malicious 
> vulnerabilities? 

To quote Schiller, "Against stupidity the gods themselves contend in vain." The 
OS can prevent am unauthorized application from accessing unauthorized data or 
elevating its privileges; it cannot prevent the application from violating its 
own specifications. The OS also cannot protect against malicious modifications; 
it's a management responsibility to vet personnel and 3rd party providing OS 
changes and other privileged code. 

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Thursday, May 30, 2019 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "An application with a trap door is an application
vulnerability. If there is a trap door in z/OS itself then that's a
platform vulnerability."

Does it really matter if an application vs z/OS has a trap door
vulnerability? In either case z/OS and the ESM's cannot function
properly when the TRAP DOOR vulnerability is exploited. Shouldn't z/OS
be able to protect itself from accidental and/or malicious
vulnerabilities? Isn't that what a platform is supposed to do? Isn't
that a requirement of a secure system?

Every program in z/OS has certain rules of the road it must abide by.
System level programs (PSW Key 0-7, Supervisor State, APF authorized)
regardless of whether they are in z/OS or an application have additional
rules they must adhere to (i.e. - they must not violate the integrity of
z/OS). These rules of the road are the responsibility of and dictated by
the platform. Integrity is a platform issue.

One of the reason's the mainframe is the most secure-able platform is at
least partially based on integrity. Integrity as implemented by the
platform is why security is possible. Without platform integrity
security is not possible. So all code (z/OS and application) that
operates at a system level (i.e. - PSW Key 0-7, Supervisor state, APF
authorized) must not violate the integrity rules. Failure of a single
program regardless of whether it is part of z/OS or an application will
allow a hacker to compromise that system and all data on it.

In response to "I'd be willing to bet a substantial amount that the
majority of penetrations in z/OS are application, configuration,
personnel and process vulnerabilities rather than z/OS vulnerabilities."

In terms of numbers of vulnerabilities there are fewer code based
vulnerabilities (TRAP DOOR is one example of a code based
vulnerabilities - there are others) vs configuration based
vulnerabilities. I would point out that a hacker only needs a single
TRAP DOOR  vulnerability to compromise the platform regardless of how
the platform is configured. So fewer code based vulnerabilities does not
help. All code based vulnerabilities have to be removed from the system
in order to secure the platform.

On 5/29/2019 2:57 PM, Seymour J Metz wrote:

>>   A single TRAP DOOR code vulnerability pierces the veil of integrity and 
>> can be used
>> to compromise the mainframe. Is this a platform weakness?
> An application with a trap door is an application vulnerability. If there is 
> a trap door in z/OS itself then that's a platform vulnerability. I'd be 
> willing to bet a substantial amount that the majority of penetrations in z/OS 
> are application, configuration, personnel and process vulnerabilities rather 
> than z/OS vulnerabilities.
>
>> Would you say that the elimination of User Key Common storage is an
>> example of a z/OS change to address a mainframe platform weakness
> Partially.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Ray Overby 
> Sent: Wednesday, May 29, 2019 11:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> In response to "Mistakes, lack of time, lack of control, lack of skills.
> Not a platform weakness." comment: The mainframe platform, z/OS, and
> ESM's all rely on integrity to function. A single TRAP DOOR code
> vulnerability pierces the veil of integ

Re: [External] Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Pommier, Rex

I have been under the impression it stands for External Security Manager, of 
which the "big 3" would be RACF, ACF2, Top Secret.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Thursday, May 30, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

I've seen the acronym ESM a few times in this thread.  I'll assume that means 
"Enterprise Security Management", and I'll guess it refers to security 
processes (not RACF), such as assigning userid's, making sure people have just 
the access they need, periodic audits, etc.

Am I even close?

On 5/30/2019 4:28 AM, Ray Overby wrote:
> In response to "An application with a trap door is an application 
> vulnerability. If there is a trap door in z/OS itself then that's a 
> platform vulnerability."
> 
> Does it really matter if an application vs z/OS has a trap door 
> vulnerability? In either case z/OS and the ESM's cannot function ...

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Tom Brennan

I've seen the acronym ESM a few times in this thread.  I'll assume that 
means "Enterprise Security Management", and I'll guess it refers to 
security processes (not RACF), such as assigning userid's, making sure 
people have just the access they need, periodic audits, etc.


Am I even close?

On 5/30/2019 4:28 AM, Ray Overby wrote:
In response to "An application with a trap door is an application 
vulnerability. If there is a trap door in z/OS itself then that's a 
platform vulnerability."


Does it really matter if an application vs z/OS has a trap door 
vulnerability? In either case z/OS and the ESM's cannot function ...


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread Bill Johnson

Nobody said it was immune and you sell z security which is quite a conflict of 
interest.

Sent from Yahoo Mail for iPhone

On Thursday, May 30, 2019, 9:17 AM, Ray Overby  wrote:

In response to "Ideed, IF you know such trap door, you know z/OS 
vulnerability, which proves the platform is not immune. Is it as 
vulnerable as Windows? No, because it's still not binary, some systems 
are still more secure than others."

In my opinion (I am biased) z/OS is the most secure-able platform that I 
know of. Secure-able (is that a word?) does not mean that the platform 
does not have vulnerabilities (configuration and code based). There are 
many people that think just like Bill Johnson. Most of them that I have 
met and talked with when presented with forensic evidence that shows 
their systems have trap doors they have accepted it (They had to report 
the problem to vendor and then apply fix - Trust but verify ;-)). Due to 
the way this industry treats integrity problems that cannot currently be 
done publicly.

In response to "Last, but not least:  assuming you know such trap door. 
Or even several trap doors. What next?"

a) I don't submit any trap doors vulnerabilities to any vendors due to 
the contractual nature around how and when these vulnerabilities are 
found. I am restricted to what I can disclose to whom. The companies 
that license the software report the issue.

b) Vendors provide a fix for trap doors in their products. I do not fix 
the Vendors code. I have not been asked to fix any installation written 
code for vulnerabilities but would if asked to.

c) If Vendor does not fix the trap door then company can now make an 
informed decision about whether to a) assume the risk and keep the 
product or  b) remove the product from the system. Having the 
vulnerability classification and knowing the capability of a trap door 
should allow the company to have meaningful internal discussions about 
the issue and decide what is best for the company. These internal 
discussion can now include management, Security, Risk, Pen testers and C 
level people all because of the vulnerability classification (TRAP DOOR) 
will allow more people to understand the issue. I would argue that 
allowing a company to understand the vulnerability risk and make an 
informed decision in the company's best interest would be very valuable 
to any company in that situation.

On 5/30/2019 6:01 AM, R.S. wrote:
> As Shmuel said an application with a trap door is an application 
> vulnerability.
> Ideed, IF you know such trap door, you know z/OS vulnerability, which 
> proves the platform is not immune. Is it as vulnerable as Windows? No, 
> because it's still not binary, some systems are still more secure than 
> others.
>
> Last, but not least:  assuming you know such trap door. Or even 
> several trap doors. What next?
> a) you submitted it to IBM and they are trying to fix it.
> b) despite of a) you know how to fix it by homegrown 
> code/configuration/procedure and you offer it as a service.
> c) the trap door cannot be fixed and then your services are disputable 
> - you cannot help.
>
> Of course the above *regards only the trap doors you know*, not your 
> services portfolio.
> Besides that you can provide many valuable services regarding 
> security, but not platform issues, rather people mistakes, 
> misconfigurations, erroneous procedures, etc.
> It is worth to emphasize: while z/OS is quite secure, it may be quite 
> complex to configure it properly. And here there is a field for Ray, 
> ITschak, RSM Partners, me, etc.
>

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Ideed, IF you know such trap door, you know z/OS 
vulnerability, which proves the platform is not immune. Is it as 
vulnerable as Windows? No, because it's still not binary, some systems 
are still more secure than others."


In my opinion (I am biased) z/OS is the most secure-able platform that I 
know of. Secure-able (is that a word?) does not mean that the platform 
does not have vulnerabilities (configuration and code based). There are 
many people that think just like Bill Johnson. Most of them that I have 
met and talked with when presented with forensic evidence that shows 
their systems have trap doors they have accepted it (They had to report 
the problem to vendor and then apply fix - Trust but verify ;-)). Due to 
the way this industry treats integrity problems that cannot currently be 
done publicly.


In response to "Last, but not least:  assuming you know such trap door. 
Or even several trap doors. What next?"


a) I don't submit any trap doors vulnerabilities to any vendors due to 
the contractual nature around how and when these vulnerabilities are 
found. I am restricted to what I can disclose to whom. The companies 
that license the software report the issue.


b) Vendors provide a fix for trap doors in their products. I do not fix 
the Vendors code. I have not been asked to fix any installation written 
code for vulnerabilities but would if asked to.


c) If Vendor does not fix the trap door then company can now make an 
informed decision about whether to a) assume the risk and keep the 
product or  b) remove the product from the system. Having the 
vulnerability classification and knowing the capability of a trap door 
should allow the company to have meaningful internal discussions about 
the issue and decide what is best for the company. These internal 
discussion can now include management, Security, Risk, Pen testers and C 
level people all because of the vulnerability classification (TRAP DOOR) 
will allow more people to understand the issue. I would argue that 
allowing a company to understand the vulnerability risk and make an 
informed decision in the company's best interest would be very valuable 
to any company in that situation.


On 5/30/2019 6:01 AM, R.S. wrote:
As Shmuel said an application with a trap door is an application 
vulnerability.
Ideed, IF you know such trap door, you know z/OS vulnerability, which 
proves the platform is not immune. Is it as vulnerable as Windows? No, 
because it's still not binary, some systems are still more secure than 
others.


Last, but not least:  assuming you know such trap door. Or even 
several trap doors. What next?

a) you submitted it to IBM and they are trying to fix it.
b) despite of a) you know how to fix it by homegrown 
code/configuration/procedure and you offer it as a service.
c) the trap door cannot be fixed and then your services are disputable 
- you cannot help.


Of course the above *regards only the trap doors you know*, not your 
services portfolio.
Besides that you can provide many valuable services regarding 
security, but not platform issues, rather people mistakes, 
misconfigurations, erroneous procedures, etc.
It is worth to emphasize: while z/OS is quite secure, it may be quite 
complex to configure it properly. And here there is a field for Ray, 
ITschak, RSM Partners, me, etc.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread John McKown

On Wed, May 29, 2019 at 1:23 PM Schuffenhauer, Mark 
wrote:

> My sales favorite was knowing key functionality is vaporware, talking up
> everything the software would do some day. Then being horrified when you
> realize the 'decision makers' are eating it up.  None of them ends up in
> hell when the product doesn't work and the functionality delivery date
> keeps getting pushed forward... but, I got to work with a 3745 until 2009.
>

I dislike some sales people's tactics. We bought a z890 and got an IFL. Two
statements: (1) Linux runs on an IFL. (2) Linux can run Windows
applications using WINE. The missing portion of statement #2 ", on an Intel
processor." Management didn't ask any technical people, they just got the
z890 + IFL. Then things got bad.

>
> Security is no good without PEN testing and auditing from the  Security
> Technical Implementation Guide (STIG) documents.  If you haven't crossed
> your eyes and dotted your teas wait, reverse that.  Your odds of solid
> security can be greatly decreased.
>
> No security by obscurity.
> EBCDIC is not a method of encryption.
> Stop people from using stupid passwords.  Ideally daily ID's have no
> elevated access, any elevated id must be checked out, activated, with a new
> password on each use.  I realize that would be messy, but if you have
> better password security(pass phrases, excluded words (months of the year,
> or seasons) or MFA going, never mind.  This isn't the paragraph you're
> looking for...
>

Although I agree with that paragraph, I have never been in a shop which
does it. The closest was when I worked for "The Equitable". I did not have
update access to datasets on the production system volumes. If I needed to
update something, such as PARMLIB, or a PROCLIB, or do SMP/E work, I had to
get with my manager; he would put in a request to the security admin; she
would grant me update authority for a short time & audit me; When I was
finished, she would revoke my access and print an audit report of my
activity while I had escalated access.

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "An application with a trap door is an application 
vulnerability. If there is a trap door in z/OS itself then that's a 
platform vulnerability."


Does it really matter if an application vs z/OS has a trap door 
vulnerability? In either case z/OS and the ESM's cannot function 
properly when the TRAP DOOR vulnerability is exploited. Shouldn't z/OS 
be able to protect itself from accidental and/or malicious 
vulnerabilities? Isn't that what a platform is supposed to do? Isn't 
that a requirement of a secure system?


Every program in z/OS has certain rules of the road it must abide by. 
System level programs (PSW Key 0-7, Supervisor State, APF authorized) 
regardless of whether they are in z/OS or an application have additional 
rules they must adhere to (i.e. - they must not violate the integrity of 
z/OS). These rules of the road are the responsibility of and dictated by 
the platform. Integrity is a platform issue.


One of the reason's the mainframe is the most secure-able platform is at 
least partially based on integrity. Integrity as implemented by the 
platform is why security is possible. Without platform integrity 
security is not possible. So all code (z/OS and application) that 
operates at a system level (i.e. - PSW Key 0-7, Supervisor state, APF 
authorized) must not violate the integrity rules. Failure of a single 
program regardless of whether it is part of z/OS or an application will 
allow a hacker to compromise that system and all data on it.


In response to "I'd be willing to bet a substantial amount that the 
majority of penetrations in z/OS are application, configuration, 
personnel and process vulnerabilities rather than z/OS vulnerabilities."


In terms of numbers of vulnerabilities there are fewer code based 
vulnerabilities (TRAP DOOR is one example of a code based 
vulnerabilities - there are others) vs configuration based 
vulnerabilities. I would point out that a hacker only needs a single 
TRAP DOOR  vulnerability to compromise the platform regardless of how 
the platform is configured. So fewer code based vulnerabilities does not 
help. All code based vulnerabilities have to be removed from the system 
in order to secure the platform.


On 5/29/2019 2:57 PM, Seymour J Metz wrote:


  A single TRAP DOOR code vulnerability pierces the veil of integrity and can 
be used
to compromise the mainframe. Is this a platform weakness?

An application with a trap door is an application vulnerability. If there is a 
trap door in z/OS itself then that's a platform vulnerability. I'd be willing 
to bet a substantial amount that the majority of penetrations in z/OS are 
application, configuration, personnel and process vulnerabilities rather than 
z/OS vulnerabilities.


Would you say that the elimination of User Key Common storage is an
example of a z/OS change to address a mainframe platform weakness

Partially.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Wednesday, May 29, 2019 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: The mainframe platform, z/OS, and
ESM's all rely on integrity to function. A single TRAP DOOR code
vulnerability pierces the veil of integrity and can be used to
compromise the mainframe. Is this a platform weakness? I think so. The
platform relies on all code it runs adhering to certain rules. z/OS
could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an
example of a z/OS change to address a mainframe platform weakness? I
think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:

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.


--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-30 Thread R.S.

As Shmuel said an application with a trap door is an application 
vulnerability.
Ideed, IF you know such trap door, you know z/OS vulnerability, which 
proves the platform is not immune. Is it as vulnerable as Windows? No, 
because it's still not binary, some systems are still more secure than 
others.


Last, but not least:  assuming you know such trap door. Or even several 
trap doors. What next?

a) you submitted it to IBM and they are trying to fix it.
b) despite of a) you know how to fix it by homegrown 
code/configuration/procedure and you offer it as a service.
c) the trap door cannot be fixed and then your services are disputable - 
you cannot help.


Of course the above *regards only the trap doors you know*, not your 
services portfolio.
Besides that you can provide many valuable services regarding security, 
but not platform issues, rather people mistakes, misconfigurations, 
erroneous procedures, etc.
It is worth to emphasize: while z/OS is quite secure, it may be quite 
complex to configure it properly. And here there is a field for Ray, 
ITschak, RSM Partners, me, etc.


--
Radoslaw Skorupka
Lodz, Poland





W dniu 2019-05-29 o 17:11, Ray Overby pisze:
In response to "Mistakes, lack of time, lack of control, lack of 
skills. Not a platform weakness." comment: The mainframe platform, 
z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR 
code vulnerability pierces the veil of integrity and can be used to 
compromise the mainframe. Is this a platform weakness? I think so. The 
platform relies on all code it runs adhering to certain rules. z/OS 
could be changed to better check and enforce those rules.


Would you say that the elimination of User Key Common storage is an 
example of a z/OS change to address a mainframe platform weakness? I 
think so.


An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:

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.


==

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: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
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: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Seymour J Metz

I'm not sure, but I suspect that a job submitted via FTP with an invalid userid 
or password would just disappear. If there is no userid then it would run under 
the userid of the server, so that should not have access to anything sensitive. 
It's not rocket science, but you do have to be careful to define appropriate 
access to the server if you allow job submission.

And, yes, security requires that you have all of the pieces in place, starting 
with management buy-in.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 7:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Thank you for the explanation.  I can see that proxy access to other userid's 
would need tight control, like a production job scheduler product has, but even 
so wouldn't the FTP server itself receive a failure if it tries to submit a job 
sent to it with invalid credentials?  Or does the job just disappear, as could 
happen (depending on various exit behaviors and your own ESM authority) if you 
TSO SUBMIT a job with a userid other than your own?

I can also see that there are lots of levels to actually effective security.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

FTP JES access relies on the credentials of the userid under which the FTP 
server is running. Under normal circumstances the user would need to provide a 
userid and password on his job card. If the FTP server has proxy access to 
other userids then it needs to be tightly controlled.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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
intende

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Seymour J Metz

I don't have enough data to estimate reliable percentages, but I have been at 
two shops where there were user SVCs for getting into key 0, without adequate 
authorization checking, and I was not permitted to remove them. In one case I 
was ordered to not point them out to an auditor. But I see that as a management 
issue rather than a platform issue.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Wednesday, May 29, 2019 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Radoslaw,

  * I find your posts informative and helpful.
  * I think your English is very understandable
  * I respect your expertise

My initial post was an attempt to get a stalled discussion moving in a
more positive direction. I don't normally post but I felt that mainframe
vulnerability discussions are important for our industry. We, as a
group, need to be able to discuss this issue without resorting to name
calling and childish behavior.

The work that I do includes finding exploitable code based
vulnerabilities running in the wild on z/OS systems. These
vulnerabilities are on mainframe systems in many sectors, including
Financial Institutions and Government. These installations report the
vulnerabilities they find and the ISV's fix them. This is a fact.
Individuals like Bill Johnson can say that I am lying. You can say what
I am saying is FUD - however, neither of these things changes the fact
that I continue to find exploitable code vulnerabilities in z/OS. More
and more people are being exposed to this fact every day.

Based on the work I have done on mainframe code vulnerabilities, I have
concluded that there is a serious problem in our industry. The code that
runs in production in all sectors has poorly written code, that if
exploited, would compromise all data on those systems. Should I just
ignore this problem or try and do something about it? The numbers of
vulnerabilities tells me there are some fundamental problems with how
software development is being done in our industry. The lives of people,
organizations, and governments would be adversely affected if the code
vulnerabilities I have found were not reported and fixed by the vendors.
I have decided that I cannot just stand by and do nothing. The industry
needs to do better. We need to do better.

In response to "What exactly hacking scenario can provide RACF db to the
hacker?" there is a class of vulnerabilities called TRAP DOOR. A TRAP
DOOR vulnerability will branch to an address specified by an
unauthorized user (key 8 problem state not apf authorized) in an
authorized state (PSW KEY 0-7, Supervisor state, JSCBAUTH bit set). This
type of vulnerability usually exists in SVC and PC routines. The address
I pass will have code to get into PSW Key 0 (code is different depending
upon the entry environment). Once in PSW Key 0 I can a) Suppress all SMF
records to hide what I am doing b) Frontend the SAF Router to force all
AUTH and FASTAUTH calls to "allow and no log" (this is for any ESM not
just RACF) c) Copy the ESM data base to another data set d) Create a
reverse shell to send it out to an IP of my choice or e) download to
windows or mac and then attach to email or f) email directly from
mainframe. Please note that once I get to PSW KEY 0 my code is now
working as an extension of z/OS. Whatever z/OS can do my code can do.
With no forensic evidence to see what I did. Or I could create ESM
credentials for Bill Johnson or Radoslaw and let it get logged to you;-)
.  Just as a FYI about 35% of the "several hundred" code vulnerabilities
that I have found are TRAP DOOR vulnerabilities. This represents a
significant percentage of total number of vulnerabilities. This is a
statically viable example.

The following is for Bill Johnson which would have been covered in the demo:

  * The SVC or PC routine can be issued by any user on the mainframe
system.
  * The vulnerable code is executed before any SAF calls are made by the
SVC or PC routine (i.e. - ESM cannot help you)
  * The ESM's:
  o Cannot identify this vulnerable code is on the system
  o Cannot tell you when the vulnerable code is exploited
  o Cannot provide you the information to get vulnerability remediated
  * The payload code does not require an APF authorized library. The
authorization is inherited from the caller (the SVC or PC routine).
  * No extra-ordinary ESM authorities are required - any id would do
  * No extra-ordinary z/Os authorizes are required
  * Suppressing SMF is for all SMF record types not just ESM records
types (i.e. - types 14 and 15)

It would be easier for this discussion if I could just create a CVE in
the national vulnerability data base. Then I could just point you to it
and you could research this for your self. However, that is not how our
industry works

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Seymour J Metz

>  A single TRAP DOOR code vulnerability pierces the veil of integrity and can 
> be used
> to compromise the mainframe. Is this a platform weakness?

An application with a trap door is an application vulnerability. If there is a 
trap door in z/OS itself then that's a platform vulnerability. I'd be willing 
to bet a substantial amount that the majority of penetrations in z/OS are 
application, configuration, personnel and process vulnerabilities rather than 
z/OS vulnerabilities.

> Would you say that the elimination of User Key Common storage is an
> example of a z/OS change to address a mainframe platform weakness

Partially.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Wednesday, May 29, 2019 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: The mainframe platform, z/OS, and
ESM's all rely on integrity to function. A single TRAP DOOR code
vulnerability pierces the veil of integrity and can be used to
compromise the mainframe. Is this a platform weakness? I think so. The
platform relies on all code it runs adhering to certain rules. z/OS
could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an
example of a z/OS change to address a mainframe platform weakness? I
think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:
> 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.
>

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Schuffenhauer, Mark

My sales favorite was knowing key functionality is vaporware, talking up 
everything the software would do some day. Then being horrified when you 
realize the 'decision makers' are eating it up.  None of them ends up in hell 
when the product doesn't work and the functionality delivery date keeps getting 
pushed forward... but, I got to work with a 3745 until 2009.

Security is no good without PEN testing and auditing from the  Security 
Technical Implementation Guide (STIG) documents.  If you haven't crossed your 
eyes and dotted your teas wait, reverse that.  Your odds of solid security 
can be greatly decreased.

No security by obscurity.
EBCDIC is not a method of encryption.
Stop people from using stupid passwords.  Ideally daily ID's have no elevated 
access, any elevated id must be checked out, activated, with a new password on 
each use.  I realize that would be messy, but if you have better password 
security(pass phrases, excluded words (months of the year, or seasons) or MFA 
going, never mind.  This isn't the paragraph you're looking for...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ray 
Overby
Sent: Wednesday, May 29, 2019 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In response to "Mistakes, lack of time, lack of control, lack of skills.
Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all 
rely on integrity to function. A single TRAP DOOR code vulnerability pierces 
the veil of integrity and can be used to compromise the mainframe. Is this a 
platform weakness? I think so. The platform relies on all code it runs adhering 
to certain rules. z/OS could be changed to better check and enforce those rules.

Would you say that the elimination of User Key Common storage is an example of 
a z/OS change to address a mainframe platform weakness? I think so.

An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:
> 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.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DISCLAIMER: This email and any attachments may contain confidential information 
that is intended solely for use by the intended recipient(s). If you are not 
the intended recipient, you are strictly prohibited from disclosing, copying, 
distributing or using any of the information contained in the communication. If 
you received this email in error, please contact the sender by reply email and 
immediately delete the communication.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Ray Overby

In response to "Mistakes, lack of time, lack of control, lack of skills. 
Not a platform weakness." comment: The mainframe platform, z/OS, and 
ESM's all rely on integrity to function. A single TRAP DOOR code 
vulnerability pierces the veil of integrity and can be used to 
compromise the mainframe. Is this a platform weakness? I think so. The 
platform relies on all code it runs adhering to certain rules. z/OS 
could be changed to better check and enforce those rules.


Would you say that the elimination of User Key Common storage is an 
example of a z/OS change to address a mainframe platform weakness? I 
think so.


An interesting observation. Thanks.

On 5/29/2019 5:25 AM, R.S. wrote:

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.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Ray Overby


Radoslaw,

 * I find your posts informative and helpful.
 * I think your English is very understandable
 * I respect your expertise

My initial post was an attempt to get a stalled discussion moving in a 
more positive direction. I don't normally post but I felt that mainframe 
vulnerability discussions are important for our industry. We, as a 
group, need to be able to discuss this issue without resorting to name 
calling and childish behavior.


The work that I do includes finding exploitable code based 
vulnerabilities running in the wild on z/OS systems. These 
vulnerabilities are on mainframe systems in many sectors, including 
Financial Institutions and Government. These installations report the 
vulnerabilities they find and the ISV's fix them. This is a fact. 
Individuals like Bill Johnson can say that I am lying. You can say what 
I am saying is FUD - however, neither of these things changes the fact 
that I continue to find exploitable code vulnerabilities in z/OS. More 
and more people are being exposed to this fact every day.


Based on the work I have done on mainframe code vulnerabilities, I have 
concluded that there is a serious problem in our industry. The code that 
runs in production in all sectors has poorly written code, that if 
exploited, would compromise all data on those systems. Should I just 
ignore this problem or try and do something about it? The numbers of 
vulnerabilities tells me there are some fundamental problems with how 
software development is being done in our industry. The lives of people, 
organizations, and governments would be adversely affected if the code 
vulnerabilities I have found were not reported and fixed by the vendors. 
I have decided that I cannot just stand by and do nothing. The industry 
needs to do better. We need to do better.


In response to "What exactly hacking scenario can provide RACF db to the 
hacker?" there is a class of vulnerabilities called TRAP DOOR. A TRAP 
DOOR vulnerability will branch to an address specified by an 
unauthorized user (key 8 problem state not apf authorized) in an 
authorized state (PSW KEY 0-7, Supervisor state, JSCBAUTH bit set). This 
type of vulnerability usually exists in SVC and PC routines. The address 
I pass will have code to get into PSW Key 0 (code is different depending 
upon the entry environment). Once in PSW Key 0 I can a) Suppress all SMF 
records to hide what I am doing b) Frontend the SAF Router to force all 
AUTH and FASTAUTH calls to "allow and no log" (this is for any ESM not 
just RACF) c) Copy the ESM data base to another data set d) Create a 
reverse shell to send it out to an IP of my choice or e) download to 
windows or mac and then attach to email or f) email directly from 
mainframe. Please note that once I get to PSW KEY 0 my code is now 
working as an extension of z/OS. Whatever z/OS can do my code can do. 
With no forensic evidence to see what I did. Or I could create ESM 
credentials for Bill Johnson or Radoslaw and let it get logged to you;-) 
.  Just as a FYI about 35% of the "several hundred" code vulnerabilities 
that I have found are TRAP DOOR vulnerabilities. This represents a 
significant percentage of total number of vulnerabilities. This is a 
statically viable example.


The following is for Bill Johnson which would have been covered in the demo:

 * The SVC or PC routine can be issued by any user on the mainframe
   system.
 * The vulnerable code is executed before any SAF calls are made by the
   SVC or PC routine (i.e. - ESM cannot help you)
 * The ESM's:
 o Cannot identify this vulnerable code is on the system
 o Cannot tell you when the vulnerable code is exploited
 o Cannot provide you the information to get vulnerability remediated
 * The payload code does not require an APF authorized library. The
   authorization is inherited from the caller (the SVC or PC routine).
 * No extra-ordinary ESM authorities are required - any id would do
 * No extra-ordinary z/Os authorizes are required
 * Suppressing SMF is for all SMF record types not just ESM records
   types (i.e. - types 14 and 15)

It would be easier for this discussion if I could just create a CVE in 
the national vulnerability data base. Then I could just point you to it 
and you could research this for your self. However, that is not how our 
industry works. Everything is secret. I used terms like "if an exploit", 
"if job reads you RACF db", "unintended consequences" to allow 
conversation without telling everyone enough information to create an 
exploit. That is the dilemma: How can we have meaningful conversations 
about vulnerabilities without exposing too much information? My answer 
is to classify the vulnerabilities. At this point we should be able to 
have meaningful conversation about any "TRAP DOOR" vulnerabilities.


In response to "Mistakes, lack of time, lack of control, lack of skills. 
Not a platform weakness." comment: People are responsible for a TRAP 
DOOR code vulnerability as

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread ITschak Mugzach

Where is the list moderator when we need him/her. Some people here
completely lost their manners.

ITschak

בתאריך יום ד׳, 29 במאי 2019, 14:19, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> Nah, I’ll go back to lurking. I forgot many of you already know everything.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. <
> 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:
>
> Questioning the integrity of a man with his credentials and background in
> mainframe security for over 30+ years? Who the hell are you that I should
> even listen to one more word from you? Better to be a fool and know it than
> open your mouth and remove all shadow of doubt.
>
> Bill, if you can overcome your arrogance, you should probably apologize.
> If not, take your trolling to some other place.
>
> One final comment: If you had consulted on a "real life event" would you
> give explicit details of who, what, when and where to some stranger?
> Especially one who has questioned the comments of everyone attempting to
> respond on this thread?
>
> I'll entertain one more response from you before I place you in the
> virtual Anton Britz lookalike folder. Make it a good one.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Johnson
> Sent: Tuesday, May 28, 2019 8:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> I posted 3-4 links from varying sources all saying the same thing. Banks,
> insurance, big retail all use the mainframe for approximately 3 major
> reasons, one of which is security. Then Ray wants to show me some
> controlled experiment that is nothing but a lab event that he can’t show to
> have ever occurred in real life. No thanks.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 6:22 PM, zMan  wrote:
>
> So...you make statements and don't back them up, and when offered
> coutner-examples, refuse to view them?
>
> Plonk.
>
> On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Demos remind me of this joke.
> > http://www.jokes.net/heavenandhell.htm
> > I’ve seen my share of demos that make claims or promises that simply
> never
> > occur.
> > Thanks Ray, I’ll pass.
> >
>
> --
> 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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Bill Johnson

Nah, I’ll go back to lurking. I forgot many of you already know everything.

Sent from Yahoo Mail for iPhone

On Wednesday, May 29, 2019, 6:02 AM, Richards, Robert B. 
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:

Questioning the integrity of a man with his credentials and background in 
mainframe security for over 30+ years? Who the hell are you that I should even 
listen to one more word from you? Better to be a fool and know it than open 
your mouth and remove all shadow of doubt.

Bill, if you can overcome your arrogance, you should probably apologize. If 
not, take your trolling to some other place.

One final comment: If you had consulted on a "real life event" would you give 
explicit details of who, what, when and where to some stranger? Especially one 
who has questioned the comments of everyone attempting to respond on this 
thread?

I'll entertain one more response from you before I place you in the virtual 
Anton Britz lookalike folder. Make it a good one. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Tuesday, May 28, 2019 8:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

I posted 3-4 links from varying sources all saying the same thing. Banks, 
insurance, big retail all use the mainframe for approximately 3 major reasons, 
one of which is security. Then Ray wants to show me some controlled experiment 
that is nothing but a lab event that he can’t show to have ever occurred in 
real life. No thanks.

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 6:22 PM, zMan  wrote:

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Richards, Robert B.

Radoslaw, you took my reply entirely wrong. I'll try to restate it better.

Over many years, banks have been very susceptible to fraud, break-ins, hackers, 
insider shananigans, corrupt employees, etc. But they have learned. Experience 
taught them that and it is a tough lesson to learn. I worked, in this century, 
for one of the largest US banks. But before that, my nuclear family banking 
experience totaled 75+ years. I've heard dozens of war stories. But I also know 
that a lot of banking fraud never was revealed to the general public less they 
take their business elsewhere. Experience has taught the banking industry some 
very tough lessons. That is what I meant. Not an attack on you or your comments 
at all. Quite the opposite. I look forward to reading your replies.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, May 29, 2019 6:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

W dniu 2019-05-29 o 12:09, Richards, Robert B. pisze:
>> I'm still sure thank banks are less susceptible to break in than regular 
>> house
> Yeah, experience is a tough task master, isn't it?
Who is task master?
Do you try to insult me?
Just because you disagree with my opinions?

-- 
Radoslaw Skorupka
Lodz, Poland




==

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: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
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: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, 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 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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread ITschak Mugzach

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. ‏<
r.skoru...@bremultibank.com.pl>:

> 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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread R.S.


W dniu 2019-05-29 o 12:09, Richards, Robert B. pisze:

I'm still sure thank banks are less susceptible to break in than regular house

Yeah, experience is a tough task master, isn't it?

Who is task master?
Do you try to insult me?
Just because you disagree with my opinions?

--
Radoslaw Skorupka
Lodz, Poland




==

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: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
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: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread R.S.


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: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
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: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread ITschak Mugzach

Radoslav,

I just tried to demonstrate the fact that ibm sometime don't confirm the
risk before it fix it and many of the industry ayyack methodd are also
posible with new technologies broght to mainframe. While i accept this
strategy from client security point of view, you can't relay on that they
tell you everything. I also agree that the z architecture is more secure.
The only thing is the gap between potential and actual. As others here, i
am doing that daily. What i see make me think i better be bald ...the are
so many attach surfaces that left unhandled. When we use our automatic
assessment, tool, most clients fails more then 50% of the tests.

Btw, win10 goes far with security, implementing micro VMs.

ITschak

בתאריך יום ד׳, 29 במאי 2019, 13:04, מאת R.S. ‏<
r.skoru...@bremultibank.com.pl>:

> W dniu 2019-05-28 o 19:01, ITschak Mugzach pisze:
> > Radoslav,
> >
> > "Claiming that z/OS has flaws as other systems is the same as claiming
> bank
> > is vulnerable to burglars as houses" I am sure you've heard of mettdown
> an
> > Spectre. IBM CPU have same issues as any other cpu in market -(
> ITschak,
> I'm sure the above is demagoguery.
> I'm still sure thank banks are less susceptible to break in than regular
> house and I'm sure z/OS is much more safe than Windows. Note: I talk
> about platform, not about people's mistakes in configuration.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
> 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, 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 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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Richards, Robert B.

> I'm still sure thank banks are less susceptible to break in than regular house

Yeah, experience is a tough task master, isn't it? 

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, May 29, 2019 6:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

W dniu 2019-05-28 o 19:01, ITschak Mugzach pisze:
> Radoslav,
>
> "Claiming that z/OS has flaws as other systems is the same as claiming bank
> is vulnerable to burglars as houses" I am sure you've heard of mettdown an
> Spectre. IBM CPU have same issues as any other cpu in market -(
ITschak,
I'm sure the above is demagoguery.
I'm still sure thank banks are less susceptible to break in than regular 
house and I'm sure z/OS is much more safe than Windows. Note: I talk 
about platform, not about people's mistakes in configuration.

-- 
Radoslaw Skorupka
Lodz, Poland




==

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: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
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: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, 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 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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread R.S.


W dniu 2019-05-28 o 19:01, ITschak Mugzach pisze:

Radoslav,

"Claiming that z/OS has flaws as other systems is the same as claiming bank
is vulnerable to burglars as houses" I am sure you've heard of mettdown an
Spectre. IBM CPU have same issues as any other cpu in market -(

ITschak,
I'm sure the above is demagoguery.
I'm still sure thank banks are less susceptible to break in than regular 
house and I'm sure z/OS is much more safe than Windows. Note: I talk 
about platform, not about people's mistakes in configuration.


--
Radoslaw Skorupka
Lodz, Poland




==

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: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
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: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-29 Thread Richards, Robert B.

Questioning the integrity of a man with his credentials and background in 
mainframe security for over 30+ years? Who the hell are you that I should even 
listen to one more word from you? Better to be a fool and know it than open 
your mouth and remove all shadow of doubt.

Bill, if you can overcome your arrogance, you should probably apologize. If 
not, take your trolling to some other place.

One final comment: If you had consulted on a "real life event" would you give 
explicit details of who, what, when and where to some stranger? Especially one 
who has questioned the comments of everyone attempting to respond on this 
thread?

I'll entertain one more response from you before I place you in the virtual 
Anton Britz lookalike folder. Make it a good one. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Tuesday, May 28, 2019 8:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

I posted 3-4 links from varying sources all saying the same thing. Banks, 
insurance, big retail all use the mainframe for approximately 3 major reasons, 
one of which is security. Then Ray wants to show me some controlled experiment 
that is nothing but a lab event that he can’t show to have ever occurred in 
real life. No thanks.

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 6:22 PM, zMan  wrote:

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

I posted 3-4 links from varying sources all saying the same thing. Banks, 
insurance, big retail all use the mainframe for approximately 3 major reasons, 
one of which is security. Then Ray wants to show me some controlled experiment 
that is nothing but a lab event that he can’t show to have ever occurred in 
real life. No thanks.

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 6:22 PM, zMan  wrote:

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

I backed them up weeks ago. Try to catch up.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 6:22 PM, zMan  wrote:

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Thank you for the explanation.  I can see that proxy access to other userid's 
would need tight control, like a production job scheduler product has, but even 
so wouldn't the FTP server itself receive a failure if it tries to submit a job 
sent to it with invalid credentials?  Or does the job just disappear, as could 
happen (depending on various exit behaviors and your own ESM authority) if you 
TSO SUBMIT a job with a userid other than your own?

I can also see that there are lots of levels to actually effective security.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 5:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

FTP JES access relies on the credentials of the userid under which the FTP 
server is running. Under normal circumstances the user would need to provide a 
userid and password on his job card. If the FTP server has proxy access to 
other userids then it needs to be tightly controlled. 
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread zMan

So...you make statements and don't back them up, and when offered
coutner-examples, refuse to view them?

Plonk.

On Tue, May 28, 2019 at 1:30 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Demos remind me of this joke.
> http://www.jokes.net/heavenandhell.htm
> I’ve seen my share of demos that make claims or promises that simply never
> occur.
> Thanks Ray, I’ll pass.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

FTP JES access relies on the credentials of the userid under which the FTP 
server is running. Under normal circumstances the user would need to provide a 
userid and password on his job card. If the FTP server has proxy access to 
other userids then it needs to be tightly controlled. 

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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 ot

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Shmuel,

Were you asking me or Ray?  For myself, I have no opinion to express about the 
security of web infrastructure.  ATM that is beyond my level of knowledge and 
expertise.

I was speaking only to the vulnerability (or not) of FTP JES access from an 
application programmer's perspective.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 28, 2019 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ray Overby
> Sent: Tuesday, May 28, 2019 11:44 AM
> To:

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What if you have a business need to make files available to the general public? 
Do you really believe that the web infrastructure is any more secure than FTP, 
or even as secure?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Tuesday, May 28, 2019 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Ray Overby
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discussion on mainframe vulnerabilities has unfortunately broken down. I 
> have been talking to mainframe people about vulnerabilities for the last 12 
> years. I have talked with people just like Bill Johnson. My discussions went 
> just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing 
> vulnerabil

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Why do you think that FTP is any more of a security issue than a web server 
that allows downloading the same files? In either case you need appropriate 
security controls.

Actually, there are far more security issues with the WWW infrastructure than 
there ever were with FTP.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Sent: Tuesday, May 28, 2019 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Ftp in general is a bad idea. Data should have a single, well protected
copy.  ibm moves to REST APIs (zosmf, but can be used natively). Again,
they need to be protected.

ITschak

בתאריך יום ג׳, 28 במאי 2019, 21:51, מאת John McKown ‏<
john.archie.mck...@gmail.com>:

> On Tue, May 28, 2019 at 12:46 PM Farley, Peter x23353 <
> peter.far...@broadridge.com> 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
> >
>
>
> I was wondering the same thing. The only thing that comes to mind is that
> more non-z/OS people know how to use ftp than tn3270. And using tn3270 to
> get to TSO to use SUBMIT requires the RACF ID to have a TSO segment. So, in
> effect, you can stop non-TSO people, who need to upload or download data,
> from submitting jobs. Assuming that such people know how to code JCL and
> issue the correct SITE command to submit to JES rather than upload into a
> data set / UNIX file.
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>
> --
> 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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

But again, if anonymous FTP is prohibited (which I can easily see is in general 
a good idea for z/OS systems; any person or organization with the business 
need/desire to use ftp to/from z/OS ought to be required to identify themselves 
first) and if I have to have valid TSO + OMVS ESM credentials in order to login 
to z/OS ftp in the first place, is there any vulnerability beyond the "insider 
threat" issue?  ISTM that so long as the ftp login is ESM controlled then FTP 
JES capability is no different in vulnerability than TSO SUBMIT + IND$FILE for 
information extraction.

I do see the potential for exploitation if the ftp configuration is not secure 
in the first place, especially if "social engineering" or other means has 
produced some valid credentials for the attacker.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Ray Overby
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discussion on mainframe vulnerabilities has unfortunately broken down. I 
> have been talking to mainframe people about vulnerabilities for the last 12 
> years. I have talked with people just like Bill Johnson. My discussions went 
> just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing 
> vulnerabilities. When the vulnerabilities were categorized (which also 
> defined their capabilities BUT does not allow the hacker to generate an
> exploit) the discussions evolved to the point that not only did the mainframe 
> people better understand the vulnerabilities and their associated risk but 
> also allowed C level, managers, Auditors, Security, Pen testers, and Risk 
> people to understand and participate in the vulnerability discussions.
>
> For example, you

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Ftp in general is a bad idea. Data should have a single, well protected
copy.  ibm moves to REST APIs (zosmf, but can be used natively). Again,
they need to be protected.

ITschak

בתאריך יום ג׳, 28 במאי 2019, 21:51, מאת John McKown ‏<
john.archie.mck...@gmail.com>:

> On Tue, May 28, 2019 at 12:46 PM Farley, Peter x23353 <
> peter.far...@broadridge.com> 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
> >
>
>
> I was wondering the same thing. The only thing that comes to mind is that
> more non-z/OS people know how to use ftp than tn3270. And using tn3270 to
> get to TSO to use SUBMIT requires the RACF ID to have a TSO segment. So, in
> effect, you can stop non-TSO people, who need to upload or download data,
> from submitting jobs. Assuming that such people know how to code JCL and
> issue the correct SITE command to submit to JES rather than upload into a
> data set / UNIX file.
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>
> --
> 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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread John McKown

On Tue, May 28, 2019 at 12:46 PM Farley, Peter x23353 <
peter.far...@broadridge.com> 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
>

I was wondering the same thing. The only thing that comes to mind is that
more non-z/OS people know how to use ftp than tn3270. And using tn3270 to
get to TSO to use SUBMIT requires the RACF ID to have a TSO segment. So, in
effect, you can stop non-TSO people, who need to upload or download data,
from submitting jobs. Assuming that such people know how to code JCL and
issue the correct SITE command to submit to JES rather than upload into a
data set / UNIX file.

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken down. I 
have been talking to mainframe people about vulnerabilities for the last 12 
years. I have talked with people just like Bill Johnson. My discussions went 
just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also defined 
their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the mainframe 
people better understand the vulnerabilities and their associated risk but also 
allowed C level, managers, Auditors, Security, Pen testers, and Risk people to 
understand and participate in the vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their source 
– configuration or code based. Classifying the vulnerability eliminates 
ambiguities that are inherent when you don’t classify. It is these ambiguities 
that can cause the discussion to break down.  For example, how would the 
discussion have changed if the vulnerabilities under discussion were classified 
as follows:

-Configuration based vulnerabilities

   * APF authorized data sets not adequately protected
   * SMP/E data sets not adequately protected
   * FTP anonymous allowed
   * FTP JES option allowed
   * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

   * Storage alteration
   * Trap door
   * System Instability


--

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 y

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Overby
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken down. I 
have been talking to mainframe people about vulnerabilities for the last 12 
years. I have talked with people just like Bill Johnson. My discussions went 
just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous. 
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also defined 
their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the mainframe 
people better understand the vulnerabilities and their associated risk but also 
allowed C level, managers, Auditors, Security, Pen testers, and Risk people to 
understand and participate in the vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their source 
– configuration or code based. Classifying the vulnerability eliminates 
ambiguities that are inherent when you don’t classify. It is these ambiguities 
that can cause the discussion to break down.  For example, how would the 
discussion have changed if the vulnerabilities under discussion were classified 
as follows:

-Configuration based vulnerabilities

  * APF authorized data sets not adequately protected
  * SMP/E data sets not adequately protected
  * FTP anonymous allowed
  * FTP JES option allowed
  * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

  * Storage alteration
  * Trap door
  * System Instability


--

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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Demos remind me of this joke.
http://www.jokes.net/heavenandhell.htm 
I’ve seen my share of demos that make claims or promises that simply never 
occur.
Thanks Ray, I’ll pass.



Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 1:20 PM, Ray Overby  wrote:

Bill - I am not interested in selling you anything. I will just demo an 
exploit of a code vulnerability. That's it.

On 5/28/2019 12:09 PM, Bill Johnson wrote:
> lol, oh it’s a demo and you sell something to fix the hole right? But, it has 
> never been exploited in the real world.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 1:06 PM, Ray Overby  wrote:
>
> Bill - I assure you the silliness is all on your part. ;-)
>
> /Show me a link to your third scenario successfully implemented? /My company 
> does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, 
> ISV and installation code. I would be happy to demo one of the 
> vulnerabilities for you with a Webex. Please email ray.ove...@krisecurity.com 
> and I will set up an exploit demo for you.
>
> //Or is this some sort of “could happen” if the stars aligned and you
> had a dozen unlikely things happen all at the same time?/ /Nope. This is the 
> real deal Bill. The demo (and any questions) should take less than 30 minutes 
> of your time.
> //
>
>
> On 5/28/2019 11:29 AM, Bill Johnson wrote:
>> Pure silliness now. As this topic always becomes.
>> I never said or insinuated the platform was immune.
>> In shops I’ve worked, very few had access to add to the APF list. Security 
>> and Audit often questioned additions. Most additions were software libs from 
>> 2-3 vendors whose libraries were also tightly controlled.
>> Show me a link to your third scenario successfully implemented? Or is this 
>> some sort of “could happen” if the stars aligned and you had a dozen 
>> unlikely things happen all at the same time?
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:
>>
>> This discussion on mainframe vulnerabilities has unfortunately broken
>> down. I have been talking to mainframe people about vulnerabilities for
>> the last 12 years. I have talked with people just like Bill Johnson. My
>> discussions went just like this discussion did. The problem (as I saw
>> it) was that discussing a “mainframe vulnerability” is too ambiguous.
>> The discussion needs to be more specific. This led to categorizing
>> vulnerabilities. When the vulnerabilities were categorized (which also
>> defined their capabilities BUT does not allow the hacker to generate an
>> exploit) the discussions evolved to the point that not only did the
>> mainframe people better understand the vulnerabilities and their
>> associated risk but also allowed C level, managers, Auditors, Security,
>> Pen testers, and Risk people to understand and participate in the
>> vulnerability discussions.
>>
>> For example, you can classify mainframe vulnerabilities based upon their
>> source – configuration or code based. Classifying the vulnerability
>> eliminates ambiguities that are inherent when you don’t classify. It is
>> these ambiguities that can cause the discussion to break down.  For
>> example, how would the discussion have changed if the vulnerabilities
>> under discussion were classified as follows:
>>
>> -Configuration based vulnerabilities
>>
>>      * APF authorized data sets not adequately protected
>>      * SMP/E data sets not adequately protected
>>      * FTP anonymous allowed
>>      * FTP JES option allowed
>>      * Outgoing TCPIP traffic not protected
>>
>> -Code based vulnerabilities
>>
>>      * Storage alteration
>>      * Trap door
>>      * System Instability
>>
>> To better focus the discussion perhaps the following questions should be
>> discussed:
>>
>> Q for Bill Johnson – Are you saying that the mainframe is immune from
>> any type of vulnerabilities (Code and Configuration based)?
>>
>> Q for Bill Johnson - Do you consider a configuration based vulnerability
>> (APF authorized data set not adequately protected) as a hack if it is
>> exploited?
>>
>> Q for Bill Johnson – Do you consider a code based vulnerability (storage
>> alteration that allows dynamic elevation of ESM or z/OS authorities by
>> any user of z/OS) as a hack if it is exploited?
>>
>>
>> On 5/28/2019 9:23 AM, Bill Johnson wrote:
>>> And you sell security services. What do I expect you to say?
>>> Not everything I provided was IBM.
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
>>> wrote:
>>>
>>> These Are IBM docs. What you expect them to say?
>>>
>>> ITschak
>>>
>>> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
>>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>>>
 On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

> If you either didn’t read or didn’t comprehend the posts I provided, I
 cannot help you.

 As I wrote, I read all of the references

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Bill - I am not interested in selling you anything. I will just demo an 
exploit of a code vulnerability. That's it.


On 5/28/2019 12:09 PM, Bill Johnson wrote:

lol, oh it’s a demo and you sell something to fix the hole right? But, it has 
never been exploited in the real world.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 1:06 PM, Ray Overby  wrote:

Bill - I assure you the silliness is all on your part. ;-)

/Show me a link to your third scenario successfully implemented? /My company 
does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, ISV 
and installation code. I would be happy to demo one of the vulnerabilities for 
you with a Webex. Please email ray.ove...@krisecurity.com and I will set up an 
exploit demo for you.

//Or is this some sort of “could happen” if the stars aligned and you
had a dozen unlikely things happen all at the same time?/ /Nope. This is the 
real deal Bill. The demo (and any questions) should take less than 30 minutes 
of your time.
//


On 5/28/2019 11:29 AM, Bill Johnson wrote:

Pure silliness now. As this topic always becomes.
I never said or insinuated the platform was immune.
In shops I’ve worked, very few had access to add to the APF list. Security and 
Audit often questioned additions. Most additions were software libs from 2-3 
vendors whose libraries were also tightly controlled.
Show me a link to your third scenario successfully implemented? Or is this some 
sort of “could happen” if the stars aligned and you had a dozen unlikely things 
happen all at the same time?


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down.  For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

     * APF authorized data sets not adequately protected
     * SMP/E data sets not adequately protected
     * FTP anonymous allowed
     * FTP JES option allowed
     * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

     * Storage alteration
     * Trap door
     * System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?


On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:


On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:


If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:


Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

lol, oh it’s a demo and you sell something to fix the hole right? But, it has 
never been exploited in the real world.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 1:06 PM, Ray Overby  wrote:

Bill - I assure you the silliness is all on your part. ;-)

/Show me a link to your third scenario successfully implemented? /My company 
does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, ISV 
and installation code. I would be happy to demo one of the vulnerabilities for 
you with a Webex. Please email ray.ove...@krisecurity.com and I will set up an 
exploit demo for you.

//Or is this some sort of “could happen” if the stars aligned and you 
had a dozen unlikely things happen all at the same time?/ /Nope. This is the 
real deal Bill. The demo (and any questions) should take less than 30 minutes 
of your time.
//


On 5/28/2019 11:29 AM, Bill Johnson wrote:
> Pure silliness now. As this topic always becomes.
> I never said or insinuated the platform was immune.
> In shops I’ve worked, very few had access to add to the APF list. Security 
> and Audit often questioned additions. Most additions were software libs from 
> 2-3 vendors whose libraries were also tightly controlled.
> Show me a link to your third scenario successfully implemented? Or is this 
> some sort of “could happen” if the stars aligned and you had a dozen unlikely 
> things happen all at the same time?
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:
>
> This discussion on mainframe vulnerabilities has unfortunately broken
> down. I have been talking to mainframe people about vulnerabilities for
> the last 12 years. I have talked with people just like Bill Johnson. My
> discussions went just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing
> vulnerabilities. When the vulnerabilities were categorized (which also
> defined their capabilities BUT does not allow the hacker to generate an
> exploit) the discussions evolved to the point that not only did the
> mainframe people better understand the vulnerabilities and their
> associated risk but also allowed C level, managers, Auditors, Security,
> Pen testers, and Risk people to understand and participate in the
> vulnerability discussions.
>
> For example, you can classify mainframe vulnerabilities based upon their
> source – configuration or code based. Classifying the vulnerability
> eliminates ambiguities that are inherent when you don’t classify. It is
> these ambiguities that can cause the discussion to break down.  For
> example, how would the discussion have changed if the vulnerabilities
> under discussion were classified as follows:
>
> -Configuration based vulnerabilities
>
>    * APF authorized data sets not adequately protected
>    * SMP/E data sets not adequately protected
>    * FTP anonymous allowed
>    * FTP JES option allowed
>    * Outgoing TCPIP traffic not protected
>
> -Code based vulnerabilities
>
>    * Storage alteration
>    * Trap door
>    * System Instability
>
> To better focus the discussion perhaps the following questions should be
> discussed:
>
> Q for Bill Johnson – Are you saying that the mainframe is immune from
> any type of vulnerabilities (Code and Configuration based)?
>
> Q for Bill Johnson - Do you consider a configuration based vulnerability
> (APF authorized data set not adequately protected) as a hack if it is
> exploited?
>
> Q for Bill Johnson – Do you consider a code based vulnerability (storage
> alteration that allows dynamic elevation of ESM or z/OS authorities by
> any user of z/OS) as a hack if it is exploited?
>
>
> On 5/28/2019 9:23 AM, Bill Johnson wrote:
>> And you sell security services. What do I expect you to say?
>> Not everything I provided was IBM.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
>> wrote:
>>
>> These Are IBM docs. What you expect them to say?
>>
>> ITschak
>>
>> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>>
>>> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>>>
 If you either didn’t read or didn’t comprehend the posts I provided, I
>>> cannot help you.
>>>
>>> As I wrote, I read all of the references that you posted.
>>> Yes, I understood them.
>>> You misrepresented what they said.
>>> Now your response is to insult me. That is pathetic.
>>>
>>> --
>>> Tom Marchant
>>>
 Sent from Yahoo Mail for iPhone


 On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
>>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
 On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:

> Mainframes are by design far more secure. For good reason. The exposure
> is catastrophic potentially. It’s one of the main reasons why banks rely
>>> and
>

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Bill - I assure you the silliness is all on your part. ;-)

/Show me a link to your third scenario successfully implemented? /My company
does not publicly disclose z/OS code vulnerabilities that it finds in z/OS, ISV
and installation code. I would be happy to demo one of the vulnerabilities for
you with a Webex. Please email ray.ove...@krisecurity.com and I will set up an
exploit demo for you.

//Or is this some sort of “could happen” if the stars aligned and you
had a dozen unlikely things happen all at the same time?/ /Nope. This is the real deal Bill. The demo (and any questions) should take less than 30 minutes of your time.

On 5/28/2019 11:29 AM, Bill Johnson wrote:

Pure silliness now. As this topic always becomes.
I never said or insinuated the platform was immune.
In shops I’ve worked, very few had access to add to the APF list. Security and
Audit often questioned additions. Most additions were software libs from 2-3
vendors whose libraries were also tightly controlled.
Show me a link to your third scenario successfully implemented? Or is this some
sort of “could happen” if the stars aligned and you had a dozen unlikely things
happen all at the same time?

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 11:44 AM, Ray Overby wrote:

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down. For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

* APF authorized data sets not adequately protected
* SMP/E data sets not adequately protected
* FTP anonymous allowed
* FTP JES option allowed
* Outgoing TCPIP traffic not protected

-Code based vulnerabilities

* Storage alteration
* Trap door
* System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?

On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:

Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

numerous

links referencing it.

You have provided pitifully little to support your claim that the

security of

mainframes is the reason banks and others stay with them. I have read
all of the references that you posted, and most of them list the

POTENTIAL

to secure them as ONE of the reasons why people use mainframes for
mission-critical data, but not the main reason.

You have

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Radoslav,

"Claiming that z/OS has flaws as other systems is the same as claiming bank
is vulnerable to burglars as houses" I am sure you've heard of mettdown an
Spectre. IBM CPU have same issues as any other cpu in market -(

ITschak

On Tue, May 28, 2019 at 7:53 PM R.S.  wrote:

> W dniu 2019-05-28 o 16:31, ITschak Mugzach pisze:
> > Bill,
> >
> > I agree that z/os has the potential to be a secure system, however people
> > configure it. What i do is to show you at real time, the delta between
> > actual and required state if hundreds of security controls. Just to make
> > z/os safe as it should.
> >
> > Most people here think the same. Z/is has the potential, my, and other
> > people , experience shows it does improve it.
>
> Now we're home. People, not platform.
> However we discuss about platform, not people.
> I understand and fully support that your company or Ray's company have
> valuable things to do, but this is related to people, not platform. You
> don't fix the platform, you fix people's mistakes.
>
> Claiming that z/OS has flaws as other systems is the same as claiming
> bank is vulnerable to burglars as houses. While both are vulnerable at
> some extent, the sentence is untrue, because the extent is different and
> the difference is significant.
> In other words no system is 100% immune, but some systems are less
> immune than others. And again: the difference is significant.
>
>
> BTW: The above remains me C2 classification for Windows NT server. One
> of the conditions was the server may not be connected to the network. ;-)
>
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
> 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: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 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: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread R.S.


W dniu 2019-05-28 o 16:31, ITschak Mugzach pisze:

Bill,

I agree that z/os has the potential to be a secure system, however people
configure it. What i do is to show you at real time, the delta between
actual and required state if hundreds of security controls. Just to make
z/os safe as it should.

Most people here think the same. Z/is has the potential, my, and other
people , experience shows it does improve it.


Now we're home. People, not platform.
However we discuss about platform, not people.
I understand and fully support that your company or Ray's company have 
valuable things to do, but this is related to people, not platform. You 
don't fix the platform, you fix people's mistakes.


Claiming that z/OS has flaws as other systems is the same as claiming 
bank is vulnerable to burglars as houses. While both are vulnerable at 
some extent, the sentence is untrue, because the extent is different and 
the difference is significant.
In other words no system is 100% immune, but some systems are less 
immune than others. And again: the difference is significant.



BTW: The above remains me C2 classification for Windows NT server. One 
of the conditions was the server may not be connected to the network. ;-)


Regards
--
Radoslaw Skorupka
Lodz, Poland




==

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: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
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: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

It's prudent to periodically review and re-evaluate everything. If the access 
for a server is consistently wrong then there is a serious problem with the 
process and I would expect it to surface on other servers. If *any* type of 
configuration error keeps happening over time then management is asleep at the 
switch.  Once is happenstance, twice is coincidence but three times is enemy 
action.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Tuesday, May 28, 2019 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Excellent suggestions for vulnerability categories.

If an exploit uses anonymous FTP wouldn't Anonymous FTP be considered
vulnerable in its current configuration? If not what would you consider
the vulnerability to be? Anonymous FTP + ESM? or ESM? or?

The remediation might be to remove the option of Anonymous FTP OR it
might be to tighten down the security for the files that are available
to the FTP id. Would it be prudent to review or re-evaluate the choice
of Anonymous FTP as part of the remediation process? Maybe? Probably?
Also, what happens if this type of vulnerability keeps happening over
time? Once is just a mistake, but an on-going re-occurring problem may
prompt a re-evaluation of Anonymous FTP.

On 5/28/2019 10:52 AM, Seymour J Metz wrote:
> What about personnel-based vulnerabilities, e.g.,
>
>  Social engineering
>  Writing down passwords
>  insider attacks
>
> Anonymous FTP is not a vulnerability per se; what is a vulnerability is 
> giving an FTP more access than is appropriate for its role. An anonymous FTP 
> server should run under a userid that only has access to those datasets that 
> should be publicly readable.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Ray Overby 
> Sent: Tuesday, May 28, 2019 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> This discussion on mainframe vulnerabilities has unfortunately broken
> down. I have been talking to mainframe people about vulnerabilities for
> the last 12 years. I have talked with people just like Bill Johnson. My
> discussions went just like this discussion did. The problem (as I saw
> it) was that discussing a “mainframe vulnerability” is too ambiguous.
> The discussion needs to be more specific. This led to categorizing
> vulnerabilities. When the vulnerabilities were categorized (which also
> defined their capabilities BUT does not allow the hacker to generate an
> exploit) the discussions evolved to the point that not only did the
> mainframe people better understand the vulnerabilities and their
> associated risk but also allowed C level, managers, Auditors, Security,
> Pen testers, and Risk people to understand and participate in the
> vulnerability discussions.
>
> For example, you can classify mainframe vulnerabilities based upon their
> source – configuration or code based. Classifying the vulnerability
> eliminates ambiguities that are inherent when you don’t classify. It is
> these ambiguities that can cause the discussion to break down.  For
> example, how would the discussion have changed if the vulnerabilities
> under discussion were classified as follows:
>
> -Configuration based vulnerabilities
>
>* APF authorized data sets not adequately protected
>* SMP/E data sets not adequately protected
>* FTP anonymous allowed
>* FTP JES option allowed
>* Outgoing TCPIP traffic not protected
>
> -Code based vulnerabilities
>
>* Storage alteration
>* Trap door
>* System Instability
>
> To better focus the discussion perhaps the following questions should be
> discussed:
>
> Q for Bill Johnson – Are you saying that the mainframe is immune from
> any type of vulnerabilities (Code and Configuration based)?
>
> Q for Bill Johnson - Do you consider a configuration based vulnerability
> (APF authorized data set not adequately protected) as a hack if it is
> exploited?
>
> Q for Bill Johnson – Do you consider a code based vulnerability (storage
> alteration that allows dynamic elevation of ESM or z/OS authorities by
> any user of z/OS) as a hack if it is exploited?
>
>
> On 5/28/2019 9:23 AM, Bill Johnson wrote:
>> And you sell security services. What do I expect you to say?
>> Not everything I provided was IBM.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
>> wrote:
>>
>> These Are IBM docs. Wh

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

05F0
0A0C


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Monday, May 27, 2019 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

[Default] On 27 May 2019 09:05:47 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>Mainframes are by design far more secure. For good reason. The exposure is 
>catastrophic potentially. It’s one of the main reasons why banks rely and stay 
>on it and spend tens of millions for it. I’ve already provided numerous links 
>referencing it. Add in my criminal justice knowledge along with my computer 
>science degree and 40 years of experience in IT and security. But don’t let me 
>dispel your beliefs.
>
Hopefully the mainframe is more secure than in the era that had at
least one university had a CRASH command that would take down the
system because so many students were finding ways to crash the system.
There are ways to secure all files and other resources but are they
used and access kept current?  The problem is keeping the system
secure while allowing people to do useful work.  The IBM mainframe has
the base facilities but are they used and considered usable?

Can someone access the system after leaving the organization?  Are
test files well secured?  Are those who have access to the system well
vetted?  Are the applications designed in a secure manner?  Is all
data entering a given computer system checked on that system even if
that data is coming from a PC or other entry device using screens
supplied by the mainframe system? On things like web servers which are
cross platform, Apache for example, is there a process in place to
keep up to date with the fixes which are also cross platform?  What is
the policy for applying integrity APARs?  If the IBM tools provided
are awkward to use, is the organization willing to spend the money for
3rd party tools to ease the burden and simplify the implementation of
the organization's policies?

The question is more not how secure a system can be made but rather
how secure the organization is willing to make it.  Is the security
implemented in a way that doesn't cause people to try finding ways of
gaming it in order to do their jobs?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
> wrote:
>
>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>apples and spiders.
>
>Are there fewer mainframe 'hacks'? Yep.  There are also exponentially fewer 
>mainframes than Windows / Android / Mac / IOS / Linux. Like - a few thousand 
>mainframes compared to 2.5 BILLION users of Windows/Linux/Mac/Android & IOS 
>combined.  That is somewhere between 250,000 - 500,000x more installs of those 
>OS's.  And they are freely available for literally anyone to poke at.
>
>What you're arguing "Because Windows gets hacked daily, and mainframes are 
>never in the news as have being hacked - means that mainframes are more secure 
>.. more 'hack-proof'"  Is like saying that:
>
>-- Homes in Toronto are more hurricane-proof because fewer of them are 
>destroyed than in Key West.
>OR
>-- Babies are better drivers than their parents, because their parents get in 
>accidents every day.
>OR
>-- People in Greenland are less susceptible to cancer because fewer people die 
>of it than do in the US.
>
>For years people thought Macs were less susceptible to viruses than their 
>Windows counterparts... because?  They never read about Mac hacks.  The 
>reality?  There were way fewer Macs.  Now?  Still much less marketshare than 
>Windows, but lots of Mac hacks/malware out there because they have more than 
>doubled their market share in 6-8 years.
>
>Mainframe hardware / software is built by humans for humans (BHFH?) and will 
>thus always have vulnerabilities and misconfigurations because we all make 
>mistakes.  Mainframe is decidedly just as hackable - by any definition of that 
>word.
>
>Cheers,
>
>Chad
>
>--
>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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Pure silliness now. As this topic always becomes.
I never said or insinuated the platform was immune.
In shops I’ve worked, very few had access to add to the APF list. Security and 
Audit often questioned additions. Most additions were software libs from 2-3 
vendors whose libraries were also tightly controlled.
Show me a link to your third scenario successfully implemented? Or is this some 
sort of “could happen” if the stars aligned and you had a dozen unlikely things 
happen all at the same time?

Sent from Yahoo Mail for iPhone

On Tuesday, May 28, 2019, 11:44 AM, Ray Overby  wrote:

This discussion on mainframe vulnerabilities has unfortunately broken 
down. I have been talking to mainframe people about vulnerabilities for 
the last 12 years. I have talked with people just like Bill Johnson. My 
discussions went just like this discussion did. The problem (as I saw 
it) was that discussing a “mainframe vulnerability” is too ambiguous. 
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also 
defined their capabilities BUT does not allow the hacker to generate an 
exploit) the discussions evolved to the point that not only did the 
mainframe people better understand the vulnerabilities and their 
associated risk but also allowed C level, managers, Auditors, Security, 
Pen testers, and Risk people to understand and participate in the 
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their 
source – configuration or code based. Classifying the vulnerability 
eliminates ambiguities that are inherent when you don’t classify. It is 
these ambiguities that can cause the discussion to break down.  For 
example, how would the discussion have changed if the vulnerabilities 
under discussion were classified as follows:

-Configuration based vulnerabilities

  * APF authorized data sets not adequately protected
  * SMP/E data sets not adequately protected
  * FTP anonymous allowed
  * FTP JES option allowed
  * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

  * Storage alteration
  * Trap door
  * System Instability

To better focus the discussion perhaps the following questions should be 
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from 
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability 
(APF authorized data set not adequately protected) as a hack if it is 
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage 
alteration that allows dynamic elevation of ESM or z/OS authorities by 
any user of z/OS) as a hack if it is exploited?

On 5/28/2019 9:23 AM, Bill Johnson wrote:
> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
>> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>>
>>> If you either didn’t read or didn’t comprehend the posts I provided, I
>> cannot help you.
>>
>> As I wrote, I read all of the references that you posted.
>> Yes, I understood them.
>> You misrepresented what they said.
>> Now your response is to insult me. That is pathetic.
>>
>> --
>> Tom Marchant
>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>>> On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>>>
 Mainframes are by design far more secure. For good reason. The exposure
 is catastrophic potentially. It’s one of the main reasons why banks rely
>> and
 stay on it and spend tens of millions for it. I’ve already provided
>> numerous
 links referencing it.
>>> You have provided pitifully little to support your claim that the
>> security of
>>> mainframes is the reason banks and others stay with them. I have read
>>> all of the references that you posted, and most of them list the
>> POTENTIAL
>>> to secure them as ONE of the reasons why people use mainframes for
>>> mission-critical data, but not the main reason.
>>>
>>> You have over-stated your case.
>>>
 Add in my criminal justice knowledge along with my computer science
 degree and 40 years of experience in IT and security. But don’t let me
 dispel your beliefs.
>>> So I shoulodn't question you because you are the expert?
>>> I call BS.
>>>
>>> --
>>> Tom Marchant
>>>
 Sent from Yahoo Mail for iPhone

 On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
>> mainfr...@bigendiansmalls.com> wrote:
 At the risk of re-kicking the already dead horse:  Bill, you're
>> comparing apples and spiders.

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls


Excellent suggestions for vulnerability categories.

If an exploit uses anonymous FTP wouldn't Anonymous FTP be considered 
vulnerable in its current configuration? If not what would you consider 
the vulnerability to be? Anonymous FTP + ESM? or ESM? or?


The remediation might be to remove the option of Anonymous FTP OR it 
might be to tighten down the security for the files that are available 
to the FTP id. Would it be prudent to review or re-evaluate the choice 
of Anonymous FTP as part of the remediation process? Maybe? Probably?  
Also, what happens if this type of vulnerability keeps happening over 
time? Once is just a mistake, but an on-going re-occurring problem may 
prompt a re-evaluation of Anonymous FTP.


On 5/28/2019 10:52 AM, Seymour J Metz wrote:

What about personnel-based vulnerabilities, e.g.,

 Social engineering
 Writing down passwords
 insider attacks

Anonymous FTP is not a vulnerability per se; what is a vulnerability is giving 
an FTP more access than is appropriate for its role. An anonymous FTP server 
should run under a userid that only has access to those datasets that should be 
publicly readable.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down.  For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

   * APF authorized data sets not adequately protected
   * SMP/E data sets not adequately protected
   * FTP anonymous allowed
   * FTP JES option allowed
   * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

   * Storage alteration
   * Trap door
   * System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?


On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:


On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:


If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:


Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

numerous

links referencing it.

You have provided pitifully little to support your claim that the

security of

mainframes is the reason banks and others stay with them. I have read
all of the references tha

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

No, it's cracking or social engineering as the case may be. Any meaningful 
discussion of security at a specific site must include at least physical 
security, software security, configuration security and personnel security.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Lennie Dymoke-Bradshaw 
Sent: Tuesday, May 28, 2019 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

In addition to defining what is "security" we need to define what we mean by 
"hacking". In my previous career at IBM I was asked this many times. At that 
time I preferred to talk of an "attack" on the mainframe, and then determine 
the susceptibility of the system to that attack.

However, I came up with some situations which could be examined to try and get 
people to define what they mean by "hacking" in this context. The questions I 
asked were the following. I suspect different folks will come up with different 
answers for some of these questions.  You will soon see, as well where the 
fault/blame/responsibility for security lies for each of these situations. 
Anyway, here are the questions I used.

1. If I use a colleague's userid and password without his knowledge, is this 
hacking? Have I hacked the mainframe?

2. If I trick a mainframe user into divulging his password, and then use this 
to access data, is this hacking? Have I hacked the mainframe?

3. If I use access I have been given in a manner which it was not designed to 
be used for (e.g. access to a break-glass userid for recovery), and so gain 
access to private data, am I hacking? Have I hacked the mainframe?

4. If I am a systems programmer and have legitimate UPDATE access to an APF 
authorised library, and use it to gain RACF SPECIAL, is this hacking? Have I 
hacked the mainframe?

5. If I have a basic userid on a z/OS system, and then discover that I can make 
use of unprotected CSA storage created by a badly coded 3rd party product which 
uses it for inter-address space communications, and I use this to gain access 
to data I would not normally have access to, is this hacking? Have I hacked the 
mainframe?

6. If I discover a bad z/OS configuration option has been used (e.g. IDCAMS in 
AUTHTSF), and I exploit it to gain access in key zero and then grant my userid 
RACF SPECIAL, am I hacking? Have I hacked the mainframe?

7. If I gain access to a DB2 userid because its password is hard-coded on a 
distributed server, and then use it to gain access to DB2 on z/OS, am I 
hacking? Have I hacked the mainframe?

8. If I discover a z/OS integrity exposure, which should be covered by the z/OS 
Statement of Integrity, and then make use of it, instead of reporting it to IBM 
to be resolved, am I hacking? Have I hacked the mainframe?

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web:  
http://secure-web.cisco.com/1qBkHi2vmFs6-X53Nw2_sH7T7jDbg-Ujkxfe0Vki7Yg4el9KCs4fJYYIV2N3d7wCg_7J9HwEStXR83_oa6cB_JRnAi1wFDWZzJFQYcGL-yDULCweDAOKvBJ-CDlpzHNf-qzURM83Y3JHhGi0FccxlMFCQpIVM-pRxphGKFq0oOAKFgWogoAxwGdt3OfTQlNeKS9qG0rzq_b5JtqrBNcfLzpFsJhUseexehN94sMG57UO3_I0XGQAYcc_4HhcZBr5e2BQXoNDIV00cY9reX97B7hl9OQ_klG1Ptpaz4qVsBXmppPmTX2p6-QB4ggzysfzL7OuLEbmUjITCFAmDO52uMkVWeoishHu_ldf6xf74azsk_ptgsy9ikTrgSWdY6W-6/http%3A%2F%2Fwww.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: 28 May 2019 08:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor Eddolls

Well, it seems 'security' needs to be defined here.
Probably like in my answer to Bill: difficulty * result.

You are secure enough if you can prevent a hacker to steal $100,= by delaying 
him for 1 hour.
You are not if you can delay him for only one hour to steal a million.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: 28 May, 2019 9:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
>
> W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> > Are there fewer mainframe 'hacks'? Yep.  There are also
> > exponentially
> fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a
> few thousand mainframes compared to 2.5 BILLION users of
> Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> 250,000 - 500,000x more installs of those OS's.  And they are freely
> available for literally anyone to poke at.
> >
> > What you're arguing "Because Windows gets hacked daily, and
> > ma

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

What about personnel-based vulnerabilities, e.g.,

Social engineering
Writing down passwords
insider attacks

Anonymous FTP is not a vulnerability per se; what is a vulnerability is giving 
an FTP more access than is appropriate for its role. An anonymous FTP server 
should run under a userid that only has access to those datasets that should be 
publicly readable.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of Ray 
Overby 
Sent: Tuesday, May 28, 2019 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken
down. I have been talking to mainframe people about vulnerabilities for
the last 12 years. I have talked with people just like Bill Johnson. My
discussions went just like this discussion did. The problem (as I saw
it) was that discussing a “mainframe vulnerability” is too ambiguous.
The discussion needs to be more specific. This led to categorizing
vulnerabilities. When the vulnerabilities were categorized (which also
defined their capabilities BUT does not allow the hacker to generate an
exploit) the discussions evolved to the point that not only did the
mainframe people better understand the vulnerabilities and their
associated risk but also allowed C level, managers, Auditors, Security,
Pen testers, and Risk people to understand and participate in the
vulnerability discussions.

For example, you can classify mainframe vulnerabilities based upon their
source – configuration or code based. Classifying the vulnerability
eliminates ambiguities that are inherent when you don’t classify. It is
these ambiguities that can cause the discussion to break down.  For
example, how would the discussion have changed if the vulnerabilities
under discussion were classified as follows:

-Configuration based vulnerabilities

  * APF authorized data sets not adequately protected
  * SMP/E data sets not adequately protected
  * FTP anonymous allowed
  * FTP JES option allowed
  * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

  * Storage alteration
  * Trap door
  * System Instability

To better focus the discussion perhaps the following questions should be
discussed:

Q for Bill Johnson – Are you saying that the mainframe is immune from
any type of vulnerabilities (Code and Configuration based)?

Q for Bill Johnson - Do you consider a configuration based vulnerability
(APF authorized data set not adequately protected) as a hack if it is
exploited?

Q for Bill Johnson – Do you consider a code based vulnerability (storage
alteration that allows dynamic elevation of ESM or z/OS authorities by
any user of z/OS) as a hack if it is exploited?

On 5/28/2019 9:23 AM, Bill Johnson wrote:
> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
>> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>>
>>> If you either didn’t read or didn’t comprehend the posts I provided, I
>> cannot help you.
>>
>> As I wrote, I read all of the references that you posted.
>> Yes, I understood them.
>> You misrepresented what they said.
>> Now your response is to insult me. That is pathetic.
>>
>> --
>> Tom Marchant
>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
>> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>>> On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>>>
>>>> Mainframes are by design far more secure. For good reason. The exposure
>>>> is catastrophic potentially. It’s one of the main reasons why banks rely
>> and
>>>> stay on it and spend tens of millions for it. I’ve already provided
>> numerous
>>>> links referencing it.
>>> You have provided pitifully little to support your claim that the
>> security of
>>> mainframes is the reason banks and others stay with them. I have read
>>> all of the references that you posted, and most of them list the
>> POTENTIAL
>>> to secure them as ONE of the reasons why people use mainframes for
>>> mission-critical data, but not the main reason.
>>>
>>> You have over-stated your case.
>>>
>>>> Add in my criminal justice knowledge along with my computer science
>>>> degree and 40 years of ex

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

This discussion on mainframe vulnerabilities has unfortunately broken 
down. I have been talking to mainframe people about vulnerabilities for 
the last 12 years. I have talked with people just like Bill Johnson. My 
discussions went just like this discussion did. The problem (as I saw 
it) was that discussing a “mainframe vulnerability” is too ambiguous. 
The discussion needs to be more specific. This led to categorizing 
vulnerabilities. When the vulnerabilities were categorized (which also 
defined their capabilities BUT does not allow the hacker to generate an 
exploit) the discussions evolved to the point that not only did the 
mainframe people better understand the vulnerabilities and their 
associated risk but also allowed C level, managers, Auditors, Security, 
Pen testers, and Risk people to understand and participate in the 
vulnerability discussions.


For example, you can classify mainframe vulnerabilities based upon their 
source – configuration or code based. Classifying the vulnerability 
eliminates ambiguities that are inherent when you don’t classify. It is 
these ambiguities that can cause the discussion to break down.  For 
example, how would the discussion have changed if the vulnerabilities 
under discussion were classified as follows:


-Configuration based vulnerabilities

 * APF authorized data sets not adequately protected
 * SMP/E data sets not adequately protected
 * FTP anonymous allowed
 * FTP JES option allowed
 * Outgoing TCPIP traffic not protected

-Code based vulnerabilities

 * Storage alteration
 * Trap door
 * System Instability

To better focus the discussion perhaps the following questions should be 
discussed:


Q for Bill Johnson – Are you saying that the mainframe is immune from 
any type of vulnerabilities (Code and Configuration based)?


Q for Bill Johnson - Do you consider a configuration based vulnerability 
(APF authorized data set not adequately protected) as a hack if it is 
exploited?


Q for Bill Johnson – Do you consider a code based vulnerability (storage 
alteration that allows dynamic elevation of ESM or z/OS authorities by 
any user of z/OS) as a hack if it is exploited?



On 5/28/2019 9:23 AM, Bill Johnson wrote:

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:


On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:


If you either didn’t read or didn’t comprehend the posts I provided, I

cannot help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <

000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:


Mainframes are by design far more secure. For good reason. The exposure
is catastrophic potentially. It’s one of the main reasons why banks rely

and

stay on it and spend tens of millions for it. I’ve already provided

numerous

links referencing it.

You have provided pitifully little to support your claim that the

security of

mainframes is the reason banks and others stay with them. I have read
all of the references that you posted, and most of them list the

POTENTIAL

to secure them as ONE of the reasons why people use mainframes for
mission-critical data, but not the main reason.

You have over-stated your case.


Add in my criminal justice knowledge along with my computer science
degree and 40 years of experience in IT and security. But don’t let me
dispel your beliefs.

So I shoulodn't question you because you are the expert?
I call BS.

--
Tom Marchant


Sent from Yahoo Mail for iPhone


On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <

mainfr...@bigendiansmalls.com> wrote:

At the risk of re-kicking the already dead horse:  Bill, you're

comparing apples and spiders.

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread John McKown

On Tue, May 28, 2019 at 10:27 AM Mike Schwab 
wrote:

> Yet many more people still break into homes vs banks despite low yield
> because of the low odds of being cot and the low penalty if you are
> caught.
>
>
"low penalty" in Texas is not necessarily true. I someone were to break
into my boss' house, he'd have to call the coroner to take the body to the
morgue. And that is totally legal in Texas. As for me, anyone with any
taste would know that my stuff isn't worth stealing. Most things I have are
around 20+ years old, excepting my gaming system & cheap laptop.

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Mike Schwab

Yet many more people still break into homes vs banks despite low yield
because of the low odds of being cot and the low penalty if you are
caught.

On Tue, May 28, 2019 at 2:09 AM Vernooij, Kees (ITOP NM) - KLM
 wrote:
>
> Then 'real reason' should be: the 'ease of breaking in' multiplied by 'the 
> result of breaking in', both weighed by personal weight factors.
> That is why some still try to break in banks.
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Bill Johnson
> > Sent: 27 May, 2019 18:20
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> >
> > Your analogies are similar to claiming houses are broken into more than
> > banks because there are more of them. Whereas the real reason is the ease
> > of breaking in.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud
> >  wrote:
> >
> > At the risk of re-kicking the already dead horse:  Bill, you're comparing
> > apples and spiders.
> >
> > Are there fewer mainframe 'hacks'? Yep.  There are also exponentially
> > fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a few
> > thousand mainframes compared to 2.5 BILLION users of
> > Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> > 250,000 - 500,000x more installs of those OS's.  And they are freely
> > available for literally anyone to poke at.
> >
> > What you're arguing "Because Windows gets hacked daily, and mainframes are
> > never in the news as have being hacked - means that mainframes are more
> > secure .. more 'hack-proof'"  Is like saying that:
> >
> > -- Homes in Toronto are more hurricane-proof because fewer of them are
> > destroyed than in Key West.
> > OR
> > -- Babies are better drivers than their parents, because their parents get
> > in accidents every day.
> > OR
> > -- People in Greenland are less susceptible to cancer because fewer people
> > die of it than do in the US.
> >
> > For years people thought Macs were less susceptible to viruses than their
> > Windows counterparts... because?  They never read about Mac hacks.  The
> > reality?  There were way fewer Macs.  Now?  Still much less marketshare
> > than Windows, but lots of Mac hacks/malware out there because they have
> > more than doubled their market share in 6-8 years.
> >
> > Mainframe hardware / software is built by humans for humans (BHFH?) and
> > will thus always have vulnerabilities and misconfigurations because we all
> > make mistakes.  Mainframe is decidedly just as hackable - by any
> > definition of that word.
> >
> > Cheers,
> >
> > Chad
> >
> > --
> > 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 information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

I agree, the biggest exposure is the people who don’t take security seriously. 
But, z/OS is inherently more secure than other platforms because of the design. 
In the bank and insurance company I worked for, security was paramount. Because 
of the data we handled. Banking records are as critical as data gets. So too 
were health insurance data. Other companies I worked, manufacturing for 
example, security was not taken as seriously. And, I’ve worked for companies 
that replaced the mainframe as well. 


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:31 AM, ITschak Mugzach  wrote:

Bill,

I agree that z/os has the potential to be a secure system, however people
configure it. What i do is to show you at real time, the delta between
actual and required state if hundreds of security controls. Just to make
z/os safe as it should.

Most people here think the same. Z/is has the potential, my, and other
people , experience shows it does improve it.

ITschak

ITschak

בתאריך יום ג׳, 28 במאי 2019, 17:23, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach 
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
> > On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
> >
> > >If you either didn’t read or didn’t comprehend the posts I provided, I
> > cannot help you.
> >
> > As I wrote, I read all of the references that you posted.
> > Yes, I understood them.
> > You misrepresented what they said.
> > Now your response is to insult me. That is pathetic.
> >
> > --
> > Tom Marchant
> >
> > >
> > >Sent from Yahoo Mail for iPhone
> > >
> > >
> > >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> > 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> > >
> > >>Mainframes are by design far more secure. For good reason. The exposure
> > >>is catastrophic potentially. It’s one of the main reasons why banks
> rely
> > and
> > >>stay on it and spend tens of millions for it. I’ve already provided
> > numerous
> > >>links referencing it.
> > >
> > >You have provided pitifully little to support your claim that the
> > security of
> > >mainframes is the reason banks and others stay with them. I have read
> > >all of the references that you posted, and most of them list the
> > POTENTIAL
> > >to secure them as ONE of the reasons why people use mainframes for
> > >mission-critical data, but not the main reason.
> > >
> > >You have over-stated your case.
> > >
> > >>Add in my criminal justice knowledge along with my computer science
> > >>degree and 40 years of experience in IT and security. But don’t let me
> > >>dispel your beliefs.
> > >
> > >So I shoulodn't question you because you are the expert?
> > >I call BS.
> > >
> > >--
> > >Tom Marchant
> > >
> > >>
> > >>Sent from Yahoo Mail for iPhone
> > >>
> > >>
> > >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> > mainfr...@bigendiansmalls.com> wrote:
> > >>
> > >>At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > >--
> > >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
>

--
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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Bill,

I agree that z/os has the potential to be a secure system, however people
configure it. What i do is to show you at real time, the delta between
actual and required state if hundreds of security controls. Just to make
z/os safe as it should.

Most people here think the same. Z/is has the potential, my, and other
people , experience shows it does improve it.

ITschak

ITschak

בתאריך יום ג׳, 28 במאי 2019, 17:23, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> And you sell security services. What do I expect you to say?
> Not everything I provided was IBM.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach 
> wrote:
>
> These Are IBM docs. What you expect them to say?
>
> ITschak
>
> בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu>:
>
> > On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
> >
> > >If you either didn’t read or didn’t comprehend the posts I provided, I
> > cannot help you.
> >
> > As I wrote, I read all of the references that you posted.
> > Yes, I understood them.
> > You misrepresented what they said.
> > Now your response is to insult me. That is pathetic.
> >
> > --
> > Tom Marchant
> >
> > >
> > >Sent from Yahoo Mail for iPhone
> > >
> > >
> > >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> > 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> > >
> > >>Mainframes are by design far more secure. For good reason. The exposure
> > >>is catastrophic potentially. It’s one of the main reasons why banks
> rely
> > and
> > >>stay on it and spend tens of millions for it. I’ve already provided
> > numerous
> > >>links referencing it.
> > >
> > >You have provided pitifully little to support your claim that the
> > security of
> > >mainframes is the reason banks and others stay with them. I have read
> > >all of the references that you posted, and most of them list the
> > POTENTIAL
> > >to secure them as ONE of the reasons why people use mainframes for
> > >mission-critical data, but not the main reason.
> > >
> > >You have over-stated your case.
> > >
> > >>Add in my criminal justice knowledge along with my computer science
> > >>degree and 40 years of experience in IT and security. But don’t let me
> > >>dispel your beliefs.
> > >
> > >So I shoulodn't question you because you are the expert?
> > >I call BS.
> > >
> > >--
> > >Tom Marchant
> > >
> > >>
> > >>Sent from Yahoo Mail for iPhone
> > >>
> > >>
> > >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> > mainfr...@bigendiansmalls.com> wrote:
> > >>
> > >>At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > >--
> > >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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

And you sell security services. What do I expect you to say?
Not everything I provided was IBM.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 10:13 AM, ITschak Mugzach  wrote:

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:

> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>
> >If you either didn’t read or didn’t comprehend the posts I provided, I
> cannot help you.
>
> As I wrote, I read all of the references that you posted.
> Yes, I understood them.
> You misrepresented what they said.
> Now your response is to insult me. That is pathetic.
>
> --
> Tom Marchant
>
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> >
> >>Mainframes are by design far more secure. For good reason. The exposure
> >>is catastrophic potentially. It’s one of the main reasons why banks rely
> and
> >>stay on it and spend tens of millions for it. I’ve already provided
> numerous
> >>links referencing it.
> >
> >You have provided pitifully little to support your claim that the
> security of
> >mainframes is the reason banks and others stay with them. I have read
> >all of the references that you posted, and most of them list the
> POTENTIAL
> >to secure them as ONE of the reasons why people use mainframes for
> >mission-critical data, but not the main reason.
> >
> >You have over-stated your case.
> >
> >>Add in my criminal justice knowledge along with my computer science
> >>degree and 40 years of experience in IT and security. But don’t let me
> >>dispel your beliefs.
> >
> >So I shoulodn't question you because you are the expert?
> >I call BS.
> >
> >--
> >Tom Marchant
> >
> >>
> >>Sent from Yahoo Mail for iPhone
> >>
> >>
> >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> mainfr...@bigendiansmalls.com> wrote:
> >>
> >>At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> >--
> >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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

These Are IBM docs. What you expect them to say?

ITschak

בתאריך יום ג׳, 28 במאי 2019, 16:54, מאת Tom Marchant ‏<
000a2a8c2020-dmarc-requ...@listserv.ua.edu>:

> On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:
>
> >If you either didn’t read or didn’t comprehend the posts I provided, I
> cannot help you.
>
> As I wrote, I read all of the references that you posted.
> Yes, I understood them.
> You misrepresented what they said.
> Now your response is to insult me. That is pathetic.
>
> --
> Tom Marchant
>
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant <
> 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
> >
> >>Mainframes are by design far more secure. For good reason. The exposure
> >>is catastrophic potentially. It’s one of the main reasons why banks rely
> and
> >>stay on it and spend tens of millions for it. I’ve already provided
> numerous
> >>links referencing it.
> >
> >You have provided pitifully little to support your claim that the
> security of
> >mainframes is the reason banks and others stay with them. I have read
> >all of the references that you posted, and most of them list the
> POTENTIAL
> >to secure them as ONE of the reasons why people use mainframes for
> >mission-critical data, but not the main reason.
> >
> >You have over-stated your case.
> >
> >>Add in my criminal justice knowledge along with my computer science
> >>degree and 40 years of experience in IT and security. But don’t let me
> >>dispel your beliefs.
> >
> >So I shoulodn't question you because you are the expert?
> >I call BS.
> >
> >--
> >Tom Marchant
> >
> >>
> >>Sent from Yahoo Mail for iPhone
> >>
> >>
> >>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud <
> mainfr...@bigendiansmalls.com> wrote:
> >>
> >>At the risk of re-kicking the already dead horse:  Bill, you're
> comparing apples and spiders.
> >
> >--
> >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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Ones, not zones.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:54 AM, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

It’s an absolute fact security is one of the main reasons the mainframe is 
still used in industries that require the best security. You can google it and 
see numerous links. I worked at a bank and can verify. Also at an insurance 
company. I also have extensive criminal justice training as well. Whether it’s 
initial security keeping bad actors out of the platform or the speed with big 
data that enables the analysis of transactions to recognize fraudulent zones.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:54 AM, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Did you ever work at a bank? I doubt it.


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:54 AM, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Tom Marchant

On Tue, 28 May 2019 13:32:35 +, Bill Johnson wrote:

>If you either didn’t read or didn’t comprehend the posts I provided, I cannot 
>help you.

As I wrote, I read all of the references that you posted.
Yes, I understood them.
You misrepresented what they said.
Now your response is to insult me. That is pathetic.

-- 
Tom Marchant

>
>Sent from Yahoo Mail for iPhone
>
>
>On Tuesday, May 28, 2019, 9:17 AM, Tom Marchant 
><000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
>On Mon, 27 May 2019 16:05:33 +, Bill Johnson wrote:
>
>>Mainframes are by design far more secure. For good reason. The exposure 
>>is catastrophic potentially. It’s one of the main reasons why banks rely and 
>>stay on it and spend tens of millions for it. I’ve already provided numerous 
>>links referencing it.
>
>You have provided pitifully little to support your claim that the security of 
>mainframes is the reason banks and others stay with them. I have read 
>all of the references that you posted, and most of them list the POTENTIAL 
>to secure them as ONE of the reasons why people use mainframes for 
>mission-critical data, but not the main reason.
>
>You have over-stated your case.
>
>>Add in my criminal justice knowledge along with my computer science 
>>degree and 40 years of experience in IT and security. But don’t let me 
>>dispel your beliefs.
>
>So I shoulodn't question you because you are the expert?
>I call BS.
>
>-- 
>Tom Marchant
>
>>
>>Sent from Yahoo Mail for iPhone
>>
>>
>>On Monday, May 27, 2019, 11:45 AM, Chad Rikansrud 
>> wrote:
>>
>>At the risk of re-kicking the already dead horse:  Bill, you're comparing 
>>apples and spiders.  
>
>--
>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

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

Exactly 


Sent from Yahoo Mail for iPhone


On Tuesday, May 28, 2019, 9:38 AM, Vernooij, Kees (ITOP NM) - KLM 
 wrote:

I would say that, at least for situations 1 to 8, you have gained unintended 
access to the mainframe via an access door that was (too) poorly protected. 
In these cases the mainframe was not the weak point, but the people (again) 
that set up the protection.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lennie Dymoke-Bradshaw
> Sent: 28 May, 2019 15:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> 
> In addition to defining what is "security" we need to define what we mean
> by "hacking". In my previous career at IBM I was asked this many times. At
> that time I preferred to talk of an "attack" on the mainframe, and then
> determine the susceptibility of the system to that attack.
> 
> However, I came up with some situations which could be examined to try and
> get people to define what they mean by "hacking" in this context. The
> questions I asked were the following. I suspect different folks will come
> up with different answers for some of these questions.  You will soon see,
> as well where the fault/blame/responsibility for security lies for each of
> these situations. Anyway, here are the questions I used.
> 
> 1. If I use a colleague's userid and password without his knowledge, is
> this hacking? Have I hacked the mainframe?
> 
> 2. If I trick a mainframe user into divulging his password, and then use
> this to access data, is this hacking? Have I hacked the mainframe?
> 
> 3. If I use access I have been given in a manner which it was not designed
> to be used for (e.g. access to a break-glass userid for recovery), and so
> gain access to private data, am I hacking? Have I hacked the mainframe?
> 
> 4. If I am a systems programmer and have legitimate UPDATE access to an
> APF authorised library, and use it to gain RACF SPECIAL, is this hacking?
> Have I hacked the mainframe?
> 
> 5. If I have a basic userid on a z/OS system, and then discover that I can
> make use of unprotected CSA storage created by a badly coded 3rd party
> product which uses it for inter-address space communications, and I use
> this to gain access to data I would not normally have access to, is this
> hacking? Have I hacked the mainframe?
> 
> 6. If I discover a bad z/OS configuration option has been used (e.g.
> IDCAMS in AUTHTSF), and I exploit it to gain access in key zero and then
> grant my userid RACF SPECIAL, am I hacking? Have I hacked the mainframe?
> 
> 7. If I gain access to a DB2 userid because its password is hard-coded on
> a distributed server, and then use it to gain access to DB2 on z/OS, am I
> hacking? Have I hacked the mainframe?
> 
> 8. If I discover a z/OS integrity exposure, which should be covered by the
> z/OS Statement of Integrity, and then make use of it, instead of reporting
> it to IBM to be resolved, am I hacking? Have I hacked the mainframe?
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: 28 May 2019 08:13
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor
> Eddolls
> 
> Well, it seems 'security' needs to be defined here.
> Probably like in my answer to Bill: difficulty * result.
> 
> You are secure enough if you can prevent a hacker to steal $100,= by
> delaying him for 1 hour.
> You are not if you can delay him for only one hour to steal a million.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of R.S.
> > Sent: 28 May, 2019 9:00
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> >
> > W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > > At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > > Are there fewer mainframe 'hacks'? Yep.  There are also
> > > exponentially
> > fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a
> > few thousand mainframes compared to 2.5 BILLION users of
> > Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> > 250,000 - 500,000x more installs of those OS's.  And they are freely
> > available for literally anyone t

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls

2019-05-28 Thread Vernooij, Kees (ITOP NM) - KLM

I would say that, at least for situations 1 to 8, you have gained unintended 
access to the mainframe via an access door that was (too) poorly protected. 
In these cases the mainframe was not the weak point, but the people (again) 
that set up the protection.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lennie Dymoke-Bradshaw
> Sent: 28 May, 2019 15:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> 
> In addition to defining what is "security" we need to define what we mean
> by "hacking". In my previous career at IBM I was asked this many times. At
> that time I preferred to talk of an "attack" on the mainframe, and then
> determine the susceptibility of the system to that attack.
> 
> However, I came up with some situations which could be examined to try and
> get people to define what they mean by "hacking" in this context. The
> questions I asked were the following. I suspect different folks will come
> up with different answers for some of these questions.  You will soon see,
> as well where the fault/blame/responsibility for security lies for each of
> these situations. Anyway, here are the questions I used.
> 
> 1. If I use a colleague's userid and password without his knowledge, is
> this hacking? Have I hacked the mainframe?
> 
> 2. If I trick a mainframe user into divulging his password, and then use
> this to access data, is this hacking? Have I hacked the mainframe?
> 
> 3. If I use access I have been given in a manner which it was not designed
> to be used for (e.g. access to a break-glass userid for recovery), and so
> gain access to private data, am I hacking? Have I hacked the mainframe?
> 
> 4. If I am a systems programmer and have legitimate UPDATE access to an
> APF authorised library, and use it to gain RACF SPECIAL, is this hacking?
> Have I hacked the mainframe?
> 
> 5. If I have a basic userid on a z/OS system, and then discover that I can
> make use of unprotected CSA storage created by a badly coded 3rd party
> product which uses it for inter-address space communications, and I use
> this to gain access to data I would not normally have access to, is this
> hacking? Have I hacked the mainframe?
> 
> 6. If I discover a bad z/OS configuration option has been used (e.g.
> IDCAMS in AUTHTSF), and I exploit it to gain access in key zero and then
> grant my userid RACF SPECIAL, am I hacking? Have I hacked the mainframe?
> 
> 7. If I gain access to a DB2 userid because its password is hard-coded on
> a distributed server, and then use it to gain access to DB2 on z/OS, am I
> hacking? Have I hacked the mainframe?
> 
> 8. If I discover a z/OS integrity exposure, which should be covered by the
> z/OS Statement of Integrity, and then make use of it, instead of reporting
> it to IBM to be resolved, am I hacking? Have I hacked the mainframe?
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: 28 May 2019 08:13
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor
> Eddolls
> 
> Well, it seems 'security' needs to be defined here.
> Probably like in my answer to Bill: difficulty * result.
> 
> You are secure enough if you can prevent a hacker to steal $100,= by
> delaying him for 1 hour.
> You are not if you can delay him for only one hour to steal a million.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of R.S.
> > Sent: 28 May, 2019 9:00
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> >
> > W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze:
> > > At the risk of re-kicking the already dead horse:  Bill, you're
> > comparing apples and spiders.
> > >
> > > Are there fewer mainframe 'hacks'? Yep.  There are also
> > > exponentially
> > fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a
> > few thousand mainframes compared to 2.5 BILLION users of
> > Windows/Linux/Mac/Android & IOS combined.  That is somewhere between
> > 250,000 - 500,000x more installs of those OS's.  And they are freely
> > available for literally anyone to poke at.
> > >
> > > What you're arguing "Because Windows gets hacked daily, and
> > > mai

Re: Fwd: Just how secure are mainframes? | Trevor Eddolls