Discussion:
Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)
(too old to reply)
Timothy Sipples
2017-08-02 07:51:40 UTC
Permalink
Yes. And hopefully the ones whose job this is are doing that.
I'm a z/OS sysprog....
It is your job, too. You just write (yes write) something like:

- - - -

August 2, 2017

Dear (My Manager):

I would like to make you aware that we are no longer receiving
security-related and other patches for the following software products and
release levels that are in productive use, as of the dates indicated:

z/OS Version 1.12 2014-09-30
CICS Transaction Server Version 3.2 2015-12-31
DB2 for z/OS Version 9.1 2014-06-27

Without security patches, and without an ongoing preventive maintenance
program to apply them, there is a growing risk of breaches. We are also
running software products that will receive security updates only for the
next 12 months or less. I can provide those details upon request.

If you have any questions, please let me know. Thanks.

(My Signature)

- - - -

That's it. You've provided the factual information, in writing (which could
be electronic), and your manager decides what to do or not to do. If you've
already done that, great. If there's a material update to provide, to keep
management reasonably well informed, please do.

Just apply a "reasonable care" standard and tell your manager, that's all.
If you're a secretary at an electric company, walking along the park one
sunny afternoon, and you see a couple people trying to steal a utility
pole, "not my job" doesn't wash. You call the police, and you tell your
boss. Likewise, if somebody has left the door open to the utility pole
depot, you ring up your company's security desk and tell them. Whether they
do anything or not is indeed *their* job, but you can observe and notify,
too.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2017-08-02 08:04:11 UTC
Permalink
Post by Timothy Sipples
Yes. And hopefully the ones whose job this is are doing that.
I'm a z/OS sysprog....
- - - -
August 2, 2017
I would like to make you aware that we are no longer receiving
security-related and other patches for the following software products and
z/OS Version 1.12 2014-09-30
CICS Transaction Server Version 3.2 2015-12-31
DB2 for z/OS Version 9.1 2014-06-27
Without security patches, and without an ongoing preventive maintenance
program to apply them, there is a growing risk of breaches. We are also
running software products that will receive security updates only for the
next 12 months or less. I can provide those details upon request.
If you have any questions, please let me know. Thanks.
(My Signature)
- - - -
That's it. You've provided the factual information, in writing (which could
be electronic), and your manager decides what to do or not to do. If you've
already done that, great. If there's a material update to provide, to keep
management reasonably well informed, please do.
Just apply a "reasonable care" standard and tell your manager, that's all.
If you're a secretary at an electric company, walking along the park one
sunny afternoon, and you see a couple people trying to steal a utility
pole, "not my job" doesn't wash. You call the police, and you tell your
boss. Likewise, if somebody has left the door open to the utility pole
depot, you ring up your company's security desk and tell them. Whether they
do anything or not is indeed *their* job, but you can observe and notify,
too.
Possible reaction:
(no paper, just shout): GET OUT, YOU'RE FIRED.

BTW: I would take care to inform my manager less officially (and keep
the notification in my archive). From personal experience I'm aware how
pointless is this ;-)
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-08-02 08:38:57 UTC
Permalink
BTW: I would take care to inform my manager less officially (and keep the notification in my archive). From personal experience I'm aware how pointless is this ;-)
Or wait for next audit or weird abend / hacking attempt, then tell manglers, supervisors and auditors.

Wait first for fireworks/drama, then wait for your retirement or dismissal letter... ;-)

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2017-08-02 08:43:46 UTC
Permalink
-----Original Message-----
Behalf Of Elardus Engelbrecht
Sent: 02 August, 2017 10:40
Subject: Re: Security, Other Risks When Unsupported (Was: z14 and z/OS
2.3 Blog Post)
Post by R.S.
BTW: I would take care to inform my manager less officially (and keep
the notification in my archive). From personal experience I'm aware how
pointless is this ;-)
Or wait for next audit or weird abend / hacking attempt, then tell
manglers, supervisors and auditors.
Wait first for fireworks/drama, then wait for your retirement or dismissal letter... ;-)
Saying: if you knew this, why didn't you tell us?

Kees.
********************************************************
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-08-02 09:04:11 UTC
Permalink
Post by Vernooij, Kees - KLM , ITOPT1
Post by Elardus Engelbrecht
BTW: I would take care to inform my manager less officially (and keep the notification in my archive). From personal experience I'm aware how pointless is this ;-)
Or wait for next audit or weird abend / hacking attempt, then tell manglers, supervisors and auditors.
Wait first for fireworks/drama, then wait for your retirement or dismissal letter... ;-)
Saying: if you knew this, why didn't you tell us?
Yup. Good question. If someone ask me your question, I'll be in serious trouble...

In fact I have seen all variants of this:

- Tell top brass directly by mouth, e-mail, formal letter.
- Tell via supervisor/auditor using above methods.
- Delegate the trouble to someone else. (really!)
- Don't tell anyone.
- Resign. Retire. Move to other dept.
...etc...

It really helps that we (from top brass to lowest ranks) have a regurlar review of all software used and their levels and PTFS/APARS/patches/license fees/etc.

IBM 'n+2' version support helps us a lot.

But what about software which are already marked as 'sunset' software, but you are still hanging on them...?

Groete / Greetings
Elardus Engelbrecht

'sunset' - dead vendor or vendor not bothering to update/support it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2017-08-02 11:33:49 UTC
Permalink
In IBM's big bag of tricks I'd take a look at Tivoli Application Dependency
Discovery Manager ("TADDM"):

https://www.ibm.com/developerworks/servicemanagement/bsm/taddm/

and perhaps add a dash of Tivoli NetView for z/OS, a tool that (among other
things) has specific SNA-related expertise.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-08-02 12:41:26 UTC
Permalink
Yes. And hopefully the ones whose job this is are doing that.
I'm a z/OS sysprog....
​Hum, around here when I "poke my nose in where it doesn't belong", it
tends to get whacked. My immediate manager is well aware of what is going
on. I am sure that he has let his manager know. It has most likely been
"risk assessed and accepted"​.

​-​
-
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mark Jacobs - Listserv
2017-08-02 13:00:53 UTC
Permalink
Been there too. Got the t-shirt and everything myself several times over
a 38 year career.

Mark Jacobs
August 2, 2017 at 8:42 AM
​Hum, around here when I "poke my nose in where it doesn't belong", it
tends to get whacked. My immediate manager is well aware of what is going
on. I am sure that he has let his manager know. It has most likely been
"risk assessed and accepted"​.
​-​
-
Veni, Vidi, VISA: I came, I saw, I did a little shopping.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
Please be alert for any emails that may ask you for login information
or directs you to login via a link. If you believe this message is a
phish or aren't sure whether this message is trustworthy, please send
August 2, 2017 at 3:52 AM
- - - -
August 2, 2017
I would like to make you aware that we are no longer receiving
security-related and other patches for the following software products and
z/OS Version 1.12 2014-09-30
CICS Transaction Server Version 3.2 2015-12-31
DB2 for z/OS Version 9.1 2014-06-27
Without security patches, and without an ongoing preventive maintenance
program to apply them, there is a growing risk of breaches. We are also
running software products that will receive security updates only for the
next 12 months or less. I can provide those details upon request.
If you have any questions, please let me know. Thanks.
(My Signature)
- - - -
That's it. You've provided the factual information, in writing (which could
be electronic), and your manager decides what to do or not to do. If you've
already done that, great. If there's a material update to provide, to keep
management reasonably well informed, please do.
Just apply a "reasonable care" standard and tell your manager, that's all.
If you're a secretary at an electric company, walking along the park one
sunny afternoon, and you see a couple people trying to steal a utility
pole, "not my job" doesn't wash. You call the police, and you tell your
boss. Likewise, if somebody has left the door open to the utility pole
depot, you ring up your company's security desk and tell them. Whether they
do anything or not is indeed *their* job, but you can observe and notify,
too.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
Please be alert for any emails that may ask you for login information
or directs you to login via a link. If you believe this message is a
phish or aren't sure whether this message is trustworthy, please send
--
Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-08-03 06:23:43 UTC
Permalink
The following Christmas party I got brave and went over to the CEO and got into a conversation about the issue.
Wow! You're that brave!
... The VP said that is all we don’t have to upgrade our machine? ... I said one caveat, and I saw everyone look at me, and I said this issue would need to be implemented by program redesign. I said the programming area would have to be involved. I thought I heard someone get out a gun but it was something like a sigh. I got the COBOL upgrade, and we pushed the end of the day back about an hour. A few months later we were told we were going to get a major hardware upgrade and software as well.
Great! You deserve a medal!

I have seen that scenario a few times in my career. Something breaks or is causing high CPU, excessive memory usage and swapping or slow transaction response time. Result - everyone screamed for a major upgrade (hardware or software)

Sometimes a simple redesign of a program resolved most of the problems. One example - I have handled a bad program problem scenario. It repeately opened a VSAM dsn, do its thing and close. Repeat - wash, rinse, repeat all of this.

Result - slow program, slow transaction times and lots of RACF SMF records (access attempt) and SYSLOG messages.

I told the programmers after looking at their programs, just please move the OPEN outside the loop and the CLOSE after the loop. Voila, all were happy.

... no, I did NOT get a T-shirt ... ;-)

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-03 13:57:40 UTC
Permalink
Post by Elardus Engelbrecht
The following Christmas party I got brave and went over to the CEO and got into a conversation about the issue.
Wow! You're that brave!
Liquid courage

CM

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-08-04 02:01:51 UTC
Permalink
Post by Charles Mills
Post by Elardus Engelbrecht
The following Christmas party I got brave and went over to the CEO and got into a conversation about the issue.
Wow! You're that brave!
Liquid courage
CM
Actually, no. I haven’t had a drink in over 30 years.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-04 13:23:57 UTC
Permalink
No offense was intended.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Edward Gould
Sent: Thursday, August 3, 2017 6:53 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)
Post by Charles Mills
Post by Elardus Engelbrecht
The following Christmas party I got brave and went over to the CEO and got into a conversation about the issue.
Wow! You're that brave!
Liquid courage
CM
Actually, no. I haven’t had a drink in over 30 years.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-08-04 02:10:32 UTC
Permalink
————————SNIP------------------------------------
I have seen that scenario a few times in my career. Something breaks or is causing high CPU, excessive memory usage and swapping or slow transaction response time. Result - everyone screamed for a major upgrade (hardware or software)
Sometimes a simple redesign of a program resolved most of the problems. One example - I have handled a bad program problem scenario. It repeately opened a VSAM dsn, do its thing and close. Repeat - wash, rinse, repeat all of this.
Result - slow program, slow transaction times and lots of RACF SMF records (access attempt) and SYSLOG messages.
I told the programmers after looking at their programs, just please move the OPEN outside the loop and the CLOSE after the loop. Voila, all were happy.
I had a similar but slightly different issue with a programmer.
They were accessing a VSAM file and each time they closed it and reopened it. I didn’t catch it till I saw a message on the console that the SMF buffer was full. I got a dump of the SMF address space and looked at it and sure enough there were thousands of VSAM open/close records. I talked to the programmers supervisor and it got changed but it took a couple of weeks. I guess I should have caught it before, but my plate was pretty full and I just didn’t have the time to look for stuff like that. I did add on a step to the dual SMF processing to catch stuff like that. Once in a while I spotted a possibility but a call to the programmer fixed the issue before it got into production.

Ed
... no, I did NOT get a T-shirt ... ;-)
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...