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 <[email protected]> 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<[email protected]> 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 [email protected] with the message: INFO IBM-MAIN > >> > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email [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
