> 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 <tro...@gmail.com> 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<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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
