Re: Looking to invoke abend in IBM PC call Service
On Thu, 18 Jan 2024 18:34:43 -0500 Joseph Reichman wrote: :>I am looking to cause an abend in IBM Service that is invoked by a PC call :>(bad parameters) so as to test out Estate Type Recovery for CBT file 192 :>If anyone has an example would appreciate it One would think placing x'' in R15-R1 should do it. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
Radoslaw, The "cracking exercise" is not so difficult. Those private keys in RACF are not encrypted. They are stored in field CERTPRVK. I think they are BER encoded. Details are in the RACF Macros and Interfaces manual. It's easy to display them using zSecure if you know how. Good reason to make sure the absolute minimum of people have READ access to the RACF database. With ICSF the keys are stored in the ICSF CKDS with each key encrypted under the ICSF master key. That master key is protected using FIP-140-2 level 4 standards. Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: 18 January 2024 22:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I hate to be a pain (Cross-Posted) Is ICSF xKDS file a VSAM? Yes. So, why to keep the keys in CKDS/PKDS instead of RACFdb? 1. Because the keys in CKDS/PKDS are *well encrypted* using secret key (CryptoExpress MK). Assumed you have CEX. 2. Because any key kept in RACF is kept along with the encryption key for that key. 3. Because still a majority of RACF installations do not use encrypted VSAM db (yet). In such scenario any authorized person (i.e. bad RACF admin) can read whole db and then do the cracking excercises. BTW: Recently I did encrypt RACF db. Results: none. Nothing happened. The database is encrypted - the only change, but it is invisible to administrators. -- Radoslaw Skorupka Lodz, Poland W dniu 17.01.2024 o 21:29, Steve Beaver pisze: > On z/OS isn't that the ICSF CKDS VSAM file? Yes > > Steve > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Farley, Peter > Sent: Wednesday, January 17, 2024 1:38 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: I hate to be a pain (Cross-Posted) > > On z/OS isn't that the ICSF CKDS VSAM file? > > Peter > > From: IBM Mainframe Discussion List On Behalf Of > Steve Beaver > Sent: Wednesday, January 17, 2024 1:32 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: I hate to be a pain (Cross-Posted) > > > This is not may area of expertise, and I can't find a YOUTUBE or a step by > > step checklist > > > > How does one create a keystore on zOS? > > > > Regards, > > > > Steve > > -- -- 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
Looking to invoke abend in IBM PC call Service
Hi I am looking to cause an abend in IBM Service that is invoked by a PC call (bad parameters) so as to test out Estate Type Recovery for CBT file 192 If anyone has an example would appreciate it Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
Is ICSF xKDS file a VSAM? Yes. So, why to keep the keys in CKDS/PKDS instead of RACFdb? 1. Because the keys in CKDS/PKDS are *well encrypted* using secret key (CryptoExpress MK). Assumed you have CEX. 2. Because any key kept in RACF is kept along with the encryption key for that key. 3. Because still a majority of RACF installations do not use encrypted VSAM db (yet). In such scenario any authorized person (i.e. bad RACF admin) can read whole db and then do the cracking excercises. BTW: Recently I did encrypt RACF db. Results: none. Nothing happened. The database is encrypted - the only change, but it is invisible to administrators. -- Radoslaw Skorupka Lodz, Poland W dniu 17.01.2024 o 21:29, Steve Beaver pisze: On z/OS isn't that the ICSF CKDS VSAM file? Yes Steve -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter Sent: Wednesday, January 17, 2024 1:38 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I hate to be a pain (Cross-Posted) On z/OS isn't that the ICSF CKDS VSAM file? Peter From: IBM Mainframe Discussion List On Behalf Of Steve Beaver Sent: Wednesday, January 17, 2024 1:32 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: I hate to be a pain (Cross-Posted) This is not may area of expertise, and I can't find a YOUTUBE or a step by step checklist How does one create a keystore on zOS? Regards, Steve -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
I gotta plead guilty to this. I know the basickest of basics about Unix security, mostly from reading "The Cuckoo's Egg" multiple times; I've also hit the manuals occasionally, but I'm woefully ignorant and I know it. I guess it helps that I know it, but it'll be better still to learn more. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I still believe that standing up for the truth of God is the greatest thing in the world. This is the end (purpose) of life. The end of life is not to be happy. The end of life is not to achieve pleasure and avoid pain. The end of life is to do the will of God, come what may. -Martin Luther King, Jr. */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Troth Sent: Thursday, January 18, 2024 11:14 What Itschak said about USS/Unix being unfamiliar to mainframe security teams is reality. Unix and USS matter when you're in a multi-platform environment (where I live). -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Thursday, January 18, 2024 08:59 unix file system is less understood and maintained by the mainframe security teams, so the risk is built in uss security (if you do not use external security for this). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I hate to be a pain (Cross-Posted)
> Files in Unix are pretty unsecure. ... That's the popular wisdom. I could argue that the evidence is circumstantial, even coincidental. (Bad rap because of bad practice by OTHER PEOPLE.) But I'll back down. What Itschak said about USS/Unix being unfamiliar to mainframe security teams is reality. Unix and USS matter when you're in a multi-platform environment (where I live). If you stay in MVS then you're better off with SAF and ICSF. -- R; <>< On 1/18/24 10:32, Colin Paice wrote: My H'penth Files in Unix are pretty unsecure. I feel that any keystore in Unix is an exposure. With ICSF you can define a public/private key pair, and protect them with a SAF profile such as RDEFINE CSFKEYS label... You then give people access to the label, and hence to the key(s). I think it is harder to get access to these RACF resources than access to Unix files, so the recommendation is use ICSF and SAF. I tend to use certificates etc in RACF and not ICSF (for ease of use) but I think ICSF is more secure. Colin On Thu, 18 Jan 2024 at 13:53, Rick Troth wrote: On 1/18/24 02:53, ITschak Mugzach wrote: see below the relevant STIG (V8r11)- TSS0-ES-000100: IBM z/OS for PKI-based authentication must use ICSF or the ESM to store keys. Why? (And I realize that YOU are not making this up, so don't take any challenge personally.) Any keys or Certificates must be managed in ICSF or the external security manager and not in UNIX files. Here too, why? I found the following, but with no rationale or justification for the above mandates. https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 "If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys." I was going to breaking that down in this note for sake of understanding, but that would be tedious. Instead I'll cut to the chase: _none of the above identifies a problem with keys residing in USS_. The statement correctly indicates the need to protect the private key, but stops short of evaluating means of protection. What is the risk? discovery of the private key. Can that happen with USS? yes (that's an area I am very familiar with) Can that happen with ICSF? you tell me (but I'll wager yes) Can that happen with an ESM? you tell me (same) Because of my familiarity with USS and things like it, combined with the common techniques used there and in other systems, it appeals to me. That's both subjective (personal) and objective (common techniques and methods, win/win). Observation: EVERY DAY I find doors closing on existing security methods in favor of obscure alternatives. The reasoning seems to be that attackers know the familiar routes and therefore the familiar routes must be avoided. That reasoning does not scale, and Wirth's law comes into play: "software is getting slower more rapidly than hardware becomes faster". Someone should expound on why ICSF or ESM is actually better or I'm calling BS on this. -- R; <>< ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: Itschak Mugzach wrote: The STIG does not allow a uss keystore. Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging what he really wants/needs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@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: VolCat - Reallocate ?
Thanks, That link didn't work for me as looked for it before this post.
Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Brian Westerman
Sent: Wednesday, January 17, 2024 1:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VolCat - Reallocate ?
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe.
You should stop all tape processing, (RMM or CA-1, or whatever you have),
because while the VOLCAT is not available no changes will work correctly.
Actually IBM says:
Quiesce tape library management with console command V
SMS,LIBRARY(libname),ALL,OFFLINE for each library sharing the volume catalog to
be moved.
Even if your volcat is really-really big, it should take no longer than a
minute or two.
Don't skip steps in the example.
For a site that volsers all start with "V" you will probably have to do both.
If you have multiple Volser ranges you might have more.
SYS1.VOLCAT.VGENERAL
SYS1.VOLCAT.VV (this is called a specific volcat, hlq.VOLCAT.Vx ('x'
being first character of a volser))
Library records reside in the general VOLCAT Volume records may reside in
either the general or specific VOLCAT - specific VOLCAT searched first.
If one is created with imbed and replicate, the other will likely be as well.
You can run the diagnose and examine ahead of time and get them out of the way
(and to make sure you don't have anything to fix).
When you export the catalog(s), do it twice as in the suggestion within step 3
because you can never have too many backups. Don't worry about the info apars
for making it faster, because unless you have millions of volumes the time
saved will not really be measurable
You will need to skip step 4 because you are changing the attributes of your
new catalog.
There are some special directions if you have multiple master catalogs that you
can skip if you have just one master catalog.
Incidentally if you ever want to just move the volcat and not change anything,
IBM has another page at
https://www.ibm.com/support/pages/how-move-volcat-new-volume that covers it.
Let me know if you need help building the JCL, It seems like a lot of work,
but it's actually quite straightforward if you read the directions.
Brian
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg]
Re: I hate to be a pain (Cross-Posted)
My H'penth Files in Unix are pretty unsecure. I feel that any keystore in Unix is an exposure. With ICSF you can define a public/private key pair, and protect them with a SAF profile such as RDEFINE CSFKEYS label... You then give people access to the label, and hence to the key(s). I think it is harder to get access to these RACF resources than access to Unix files, so the recommendation is use ICSF and SAF. I tend to use certificates etc in RACF and not ICSF (for ease of use) but I think ICSF is more secure. Colin On Thu, 18 Jan 2024 at 13:53, Rick Troth wrote: > On 1/18/24 02:53, ITschak Mugzach wrote: > > see below the relevant STIG (V8r11)- TSS0-ES-000100: > > > > IBM z/OS for PKI-based authentication must use ICSF or the ESM to store > > keys. > > > Why? > (And I realize that YOU are not making this up, so don't take any > challenge personally.) > > > > Any keys or Certificates must be managed in ICSF or the external security > > manager and not in UNIX files. > > > Here too, why? > > I found the following, but with no rationale or justification for the > above mandates. > > https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 > > "If the private key is discovered, an attacker can use the key to > authenticate as an authorized user and gain access to the network > infrastructure. The cornerstone of the PKI is the private key used to > encrypt or digitally sign information. If the private key is stolen, > this will lead to the compromise of the authentication and > non-repudiation gained through PKI because the attacker can use the > private key to digitally sign documents and pretend to be the authorized > user. Both the holders of a digital certificate and the issuing > authority must protect the computers, storage devices, or whatever they > use to keep the private keys." > > I was going to breaking that down in this note for sake of > understanding, but that would be tedious. > Instead I'll cut to the chase: _none of the above identifies a problem > with keys residing in USS_. The statement correctly indicates the need > to protect the private key, but stops short of evaluating means of > protection. > > What is the risk? discovery of the private key. > > Can that happen with USS? yes (that's an area I am very familiar with) > > Can that happen with ICSF? you tell me (but I'll wager yes) > > Can that happen with an ESM? you tell me (same) > > Because of my familiarity with USS and things like it, combined with the > common techniques used there and in other systems, it appeals to me. > That's both subjective (personal) and objective (common techniques and > methods, win/win). > > Observation: > EVERY DAY I find doors closing on existing security methods in favor of > obscure alternatives. > The reasoning seems to be that attackers know the familiar routes and > therefore the familiar routes must be avoided. > That reasoning does not scale, and Wirth's law comes into play: > "software is getting slower more rapidly than hardware becomes faster". > > Someone should expound on why ICSF or ESM is actually better or I'm > calling BS on this. > > -- R; <>< > > > > ITschak Mugzach > > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > > for z/OS, x/Linux & IBM I **| z/VM coming soon * > > > > > > > > > > On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: > > > >> Itschak Mugzach wrote: > >>> The STIG does not allow a uss keystore. > >> Ummmkay? I see no mention of a STIG here. But as I said, I'm even > SWAGging > >> what he really wants/needs. > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email tolists...@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: I hate to be a pain (Cross-Posted)
Rick, You blond the messenger. STIGs are developed by DISA. We only automate the process. This is why I am very familiar with the STIG rules. Btw, unix file system is less understood and maintained by the mainframe security teams, so the risk is built in uss security (if you do not use external security for this). ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום ה׳, 18 בינו׳ 2024 ב-15:53 מאת Rick Troth : > On 1/18/24 02:53, ITschak Mugzach wrote: > > see below the relevant STIG (V8r11)- TSS0-ES-000100: > > > > IBM z/OS for PKI-based authentication must use ICSF or the ESM to store > > keys. > > > Why? > (And I realize that YOU are not making this up, so don't take any > challenge personally.) > > > > Any keys or Certificates must be managed in ICSF or the external security > > manager and not in UNIX files. > > > Here too, why? > > I found the following, but with no rationale or justification for the > above mandates. > > https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 > > "If the private key is discovered, an attacker can use the key to > authenticate as an authorized user and gain access to the network > infrastructure. The cornerstone of the PKI is the private key used to > encrypt or digitally sign information. If the private key is stolen, > this will lead to the compromise of the authentication and > non-repudiation gained through PKI because the attacker can use the > private key to digitally sign documents and pretend to be the authorized > user. Both the holders of a digital certificate and the issuing > authority must protect the computers, storage devices, or whatever they > use to keep the private keys." > > I was going to breaking that down in this note for sake of > understanding, but that would be tedious. > Instead I'll cut to the chase: _none of the above identifies a problem > with keys residing in USS_. The statement correctly indicates the need > to protect the private key, but stops short of evaluating means of > protection. > > What is the risk? discovery of the private key. > > Can that happen with USS? yes (that's an area I am very familiar with) > > Can that happen with ICSF? you tell me (but I'll wager yes) > > Can that happen with an ESM? you tell me (same) > > Because of my familiarity with USS and things like it, combined with the > common techniques used there and in other systems, it appeals to me. > That's both subjective (personal) and objective (common techniques and > methods, win/win). > > Observation: > EVERY DAY I find doors closing on existing security methods in favor of > obscure alternatives. > The reasoning seems to be that attackers know the familiar routes and > therefore the familiar routes must be avoided. > That reasoning does not scale, and Wirth's law comes into play: > "software is getting slower more rapidly than hardware becomes faster". > > Someone should expound on why ICSF or ESM is actually better or I'm > calling BS on this. > > -- R; <>< > > > > ITschak Mugzach > > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > > for z/OS, x/Linux & IBM I **| z/VM coming soon * > > > > > > > > > > On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: > > > >> Itschak Mugzach wrote: > >>> The STIG does not allow a uss keystore. > >> Ummmkay? I see no mention of a STIG here. But as I said, I'm even > SWAGging > >> what he really wants/needs. > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email tolists...@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: I hate to be a pain (Cross-Posted)
On 1/18/24 02:53, ITschak Mugzach wrote: see below the relevant STIG (V8r11)- TSS0-ES-000100: IBM z/OS for PKI-based authentication must use ICSF or the ESM to store keys. Why? (And I realize that YOU are not making this up, so don't take any challenge personally.) Any keys or Certificates must be managed in ICSF or the external security manager and not in UNIX files. Here too, why? I found the following, but with no rationale or justification for the above mandates. https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883 "If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys." I was going to breaking that down in this note for sake of understanding, but that would be tedious. Instead I'll cut to the chase: _none of the above identifies a problem with keys residing in USS_. The statement correctly indicates the need to protect the private key, but stops short of evaluating means of protection. What is the risk? discovery of the private key. Can that happen with USS? yes (that's an area I am very familiar with) Can that happen with ICSF? you tell me (but I'll wager yes) Can that happen with an ESM? you tell me (same) Because of my familiarity with USS and things like it, combined with the common techniques used there and in other systems, it appeals to me. That's both subjective (personal) and objective (common techniques and methods, win/win). Observation: EVERY DAY I find doors closing on existing security methods in favor of obscure alternatives. The reasoning seems to be that attackers know the familiar routes and therefore the familiar routes must be avoided. That reasoning does not scale, and Wirth's law comes into play: "software is getting slower more rapidly than hardware becomes faster". Someone should expound on why ICSF or ESM is actually better or I'm calling BS on this. -- R; <>< ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III wrote: Itschak Mugzach wrote: The STIG does not allow a uss keystore. Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging what he really wants/needs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@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
