In response to "What convention? The z/OS platform is (mostly) secure."
z/OS is the most secure-able platform I know. However, a z/OS
installation is only secure when the installation configures it
correctly AND all programs running on the system do not violate the
statement of integrity. Both must be true or it is not secure.
In response to "If the user adds authorized code then it is no longer
IBM's platform, and security vulnerabilities caused by not following the
statement of integrity are vulnerabilities in the installation, not in
z/OS."
Please assume a TRAP DOOR vulnerability is in IBM, ISV, or installation
written code for this. That will help focus the discussion.
* Do the capabilities of the code vulnerability change based on whose
code the vulnerability is located in? I don't think so - it
certainly does not for a TRAP DOOR.
* Does the vulnerability risk to the installation change based upon
whose code the vulnerability is located in? I don't think so - it
certainly does not for a TRAP DOOR.
* Does the installation, whose mainframe has exploitable code
vulnerabilities, really care if the vulnerabilities come from IBM,
ISV's, or installation written code? Yes, but only because they
will need to know in order to report the problem to get a fix.
I do not see that your distinction between an "IBM platform" and an
"Installation Platform" helpful for an installation when it is trying to
deal with exploitable code vulnerabilities. Perhaps there is a reason
that I don't see.
Something that might help this discussion (I would suggest this be done
periodically - for example monthly):
* How many integrity vulnerabilities are located in an installations
CSI's GLOBAL zones?
* How many are in apply status?
* How many new ones are there each reporting period?
My company does not have access to this data so I don't really know the
answers. Perhaps someone else could report it (assuming that does not
violate some legal agreement). Even if you don't report it the
information may be enlightening.
I think people need to understand - TRAP DOORS (as well as other
vulnerability categories) exist in IBM, ISV, and installation code on a
regular basis based upon the data my company has acquired. As others
have pointed out my company does not find all code vulnerabilities but
we still have found several hundred. Code vulnerabilities are not a once
in a lifetime occurrence as most people assume. The numbers are not like
the other platforms but they are greater than what most would expect.
Perhaps if someone reports the information in their SMP/E CSI's that
might shed more light on this subject.
In response to "Now, when *IBM* fails to follow the statement of
integrity, that *is* a z/OS vulnerability, but when is the last time
that IBM refused to correct such an error when it was reported?"
I attribute this to Mark Nelson (IBM) - I am paraphrasing - Mark -
please correct this if I get this wrong - That IBM has corrected all
accepted integrity problems with one exception. Mark thought that the
product with the vulnerability was removed from marketing. This one
exception caused a change to the IBM statement of integrity to "IBM will
always take action".
I think the problem here is that some people assume that there are no
integrity problems in IBM code. IBM's statement of integrity clearly
states that if an integrity problem is found and accepted by IBM that
they will take some action. Periodic review of the SMP/E CSI's will
establish whether or not there are any integrity fix's.
On 5/31/2019 12:29 PM, Seymour J Metz wrote:
What convention? The z/OS platform is (mostly) secure. If the user adds
authorized code then it is no longer IBM's platform, and security
vulnerabilities caused by not following the statement of integrity are
vulnerabilities in the installation, not in z/OS.
Now, when *IBM* fails to follow the statement of integrity, that *is* a z/OS
vulnerability, but when is the last time that IBM refused to correct such an
error when it was reported?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Wayne
Driscoll <[email protected]>
Sent: Thursday, May 30, 2019 5:20 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
If the trap door is in an APF authorized library, then by convention it's part
of the operating system, and would be considered a platform issue. Anything
that is APF authorized is expected to adhere to the statement of integrity that
z/OS publishes.
Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Seymour J Metz
Sent: Wednesday, May 29, 2019 2:58 PM
To: [email protected]
Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
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
https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C4ec98728280a4395aab708d6e46ff2fd%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636947566821955527&sdata=Ggtx2UoZolPoAJZgbcdFshw16B%2B1Yy998xUO7Bts%2FzU%3D&reserved=0
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Ray
Overby <[email protected]>
Sent: Wednesday, May 29, 2019 11:11 AM
To: [email protected]
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
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support:
https://secure-web.cisco.com/1Sx3aGBNDdC-i6lMJ3SYQf94xr7-uJ29cf49tPteg8EumjwYoSxEcUL9FgNj8iG98vHvMgCxxHlQdap3rMDI9ajg0gouV6tUjrZ8eNZENLl3so_IVtpukfpXY3RWMLUWGbP5HsbwqtMUM_p30Gub90nCbulp_yWTJ6VgYs9Qw9YpMRETBrkwbBEJ3n0wM_gI0tTD_cYCB7hl1QvvNQAV8xHFVJFSLkt4psG8MqyHcEycm-QRVwU6mxjGOVrK1P5TpegYPUzvLe2jLh0crwXVN4TJAcQEZDcowXP-q0QFnr87UEbU5pNhDH-dh4pSe1Y9-XiqUDGbnxIKBnHLBVupAOwPnne4jC542DSVZL4U2OLP8O3s1ltJnijdjGck5_uH9HPPwPMZwKqq7r24tD2zCU3mkhddBxA-1UjT0pVXT_SuyXwZ63_-XcT6xeJvpbxTv/https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
http://secure-web.cisco.com/1rQaTFN6UUseMQmfhu8LgDt4pa7bWVwMV3ujEAT-sE6745cgKJQsM4WE4Mgrjh4LYQf38_o0D9J6AJmX4nNX9lEiS4w5dtsoJXuRozhwzOxpcoomhEfVTWoFpwVM-pRqnJ7vXyGBwOHBwC0YMyaM75sNZdfeAWqfweQZqPcvGVBoQSEnt7cWJzMUW6yHxoTqRaFicKx73U_hRCZMrTVRkxmvRtySi_FfEUg7_IOfU2tLPbqMKkxwpuEL_tYPaCcVNdOiFtMFuwCnv7gXs0MPkp7VI7BWHyEqycUopxPeTCWM7sIK_ROXX5fT8h9UkCw7nFnvNA-_t3Yp1YXXlHwYhYcBjuUuKTLKMBwQRcUdA3IYLSXJYbWUHMKgRx7smJkSeA6IAb_1hAsJdc-nIQJ8CSAe8bkvOVZEdmYLEa_ICoP9cFKKAjspLTik8Tv3qMMDE/http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences
Privacy Policy -
http://secure-web.cisco.com/1nklBz-Z6IM8tzCR5_GWdb14WwlulitDUUWn3NUecDqqEpL6uaRXVCw1rCAU8Tx-8wdA1fy1qA-IBLCskPK8q_N0A8DcxbbKkzZfIfGWrpaWIe_Vxuf_ba5BeIo0SIogzgX9w-NCglLXcMW391MdSvPuMzL3RxbEJBvb-WXQ8ksBIgSw4QRldGpBH8plaeDQSTmavtu2upK9k5o6bckJhM_DrExWPThzoxspX6pr3KKENT39lzo8jX-aIHuNlqElyuMFkkQrujdGvV9r7PALjl9vbdTbRZ20Sk7LN-Lomi20ZaHeWR0l76VaiuX2id_oStyiIAmu-lkFIjAHg0H_JojcGFZWHLE3iK1nuoFMJFYd_DAV13_R7aspOr3JM_mk-DVaHBGbXzV1vCj5fWb9eKw9RZ23dJV0Howbc56tyYj-7p1POjY6mnWYYqxY6ZWGY/http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy
================================
This communication and any attachments may contain confidential information of
Rocket Software, Inc. All unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please notify Rocket
Software immediately and destroy all copies of this communication. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
