Tony Harminc wrote:
>Yes, storage administrators are a small population, but their
>credentials can be compromised as much as anyone else's, and then
>you're not dealing with rogue storage admins but with criminal (or
>goverment or whatever) actors. And storage admins (or their
>credentials) may we
Well that's a good point, Charles. A relatively minor risk, compared to
external attackers, but I suppose they could come in via the sandbox/test
system, too.
Definitely a "Swiss cheese attack"!
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Fr
On Fri, 12 Apr 2024 at 12:22, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> [...]
> I personally am still having a hard time wrapping my head around the “real
> benefit” of dataset encryption. Everyone who has READ or more access to
> the dataset, must also be permitte
"You lose/destroy the key(s), you have lost your data." My answer: "You
lose/destroy the password(s), you have lost your data." Do you use RACF
(or TSS, ACF2)? Oh, it is not a joke. I know such scenario. Government
owned organisation. Yes, every new thing does require some preparation
and proce
Dataset encryption also guards against the situation in which a sandbox or test
LPAR (1) has very permissive RACF definitions and (2) inadvertently has shared
access to production DASD.
Charles
On Fri, 12 Apr 2024 14:38:22 -0400, Steve Thompson wrote:
>I clipped this to get to what I think is
We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices,
all internal disk storage, no external cartridge tapes. So what does
that do for the customer, since (unless you're using an additional form
of encryption on the mainframe) the data is still spit out of the
devices unencryp
I clipped this to get to what I think is the real question being
asked.
Suppose that I am a person who has access for D/R purposes to all
data sets in a data center. I only need to be able copy files. I
don't have a need read the data in the file, just get it to the
D/R system/LPAR/data cente
Where it should also be encrypted and secured against malicious actors.
Eric Rossman
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Colin Paice
Sent: Friday, April 12, 2024 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM key management products
Th
The file is encrypted on route, and the file then sits on my laptop for 2
days, before I pass it on
Colin
On Fri, 12 Apr 2024 at 17:44, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> Colin,
>
> Yes, but that can and should be secured via encrypted connection.
>
> Dave Jo
Colin,
Yes, but that can and should be secured via encrypted connection.
Dave Jousma
Vice President | Director, Technology Engineering
From: IBM Mainframe Discussion List on behalf of
Colin Paice <059d4daca697-dmarc-requ...@listserv.ua.edu>
Date: Friday, April 12, 2024 at 12:28 PM
To:
I too struggled with why we need data set encryption. Someone pointed out
data in transit, for example FTPing it or copying it to a non z/OS system
Colin
On Fri, 12 Apr 2024 at 17:22, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> To place a bit more focus on what Rick
To place a bit more focus on what Rick says….. You lose/destroy the key(s),
you have lost your data. There is a lot of discussion about the scope/use of
the keys. One key, or one per application, or one per dataset, etc. There
is no right/wrong answer (well just one key for everything is
Not discounting Luke's excellent response: key management is hard.
Look for utilities with reliable import/export capability. Be prepared
to OWN your keys.
I say this again as a CISSP, own your keys. This is your bread and
butter, so to speak, the family jewels.
So take care when using these pro
Most of them are just different names for the same products.
IBM GKLM (Guardium Key Lifecycle Manager) is the latest name for what was once
known as TKLM, SKLM. I believe ISKLM is the z/OS version of the product.
https://community.ibm.com/community/user/security/discussion/what-is-ibm-gklm-are-g
14 matches
Mail list logo