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 <tro...@gmail.com>: > 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<li...@akphs.com> 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
