Re: Pervasive Encryption - why?

[Timothy Sipples]

Phil Smith III wrote:
>Timothy Sipples disagrees, which is his right,
>but the industry doesn't, so I'm not sure what
>else to say here.

To recap, you claimed this:

>Read about data-centric protection, note the analysts and
>standards bodies saying that container-level protection is
>just not very useful.

z/OS Data Set Encryption is not container-level encryption, at least not if
you respect reasonable precision in terminology. (Are you referring to
Docker container-level encryption, for example?) It's file-level
encryption. Data sets are files that contain one or more records (formal
definition).

You could start by citing specific analysts and standards bodies (your
plurals and conjunction) that claim that file-level encryption "is just not
very useful." That's your (corrected) claim, not mine.

You've already agreed with the "pyramid," even pointing out that you've
been using a similar diagram in your presentations for "years." Are you now
pushing for a lesser pyramid? :-)


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Ron Hawkins]

Phil,

Yes, you understood my question. Thank you.

I'm surprised by "Repeatability-XYZ encrypts to (perhaps) ABC consistently",
but if it works as you describe, then I think the impact would not be huge.
My observation is that compressing random ciphers is like compressing random
floating-point numbers: keep poking that stick in your eye.

I think this applies equally to things like transaction files, where account
numbers often repeat for many records, which often are sorted or grouped. If
the account number cypher is always the same, then it would get an entry in
the dictionary.

However, from what you explain, prefixes on account numbers, like the first
four of a credit card number, would no longer be the same for groups of
records, so that would mean some loss of repeatability.

RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Friday, 9 August 2019 01:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

Ron Hawkins wrote:

>That would be an improvement over a random cypher, but wouldn't the 
>length

>and repeatability of the data patterns after encryption negatively 
>affect

>LZW compression, along with deduplication?

 

Not sure I understand your question, but I'll try.

 

Length-is unchanged

 

Repeatability-XYZ encrypts to (perhaps) ABC consistently, so it's
repeatable. But WXYZ does not encrypt to xABC, so is that what you mean
about repeatability? Yes, that will affect compression to some extent. My
suspicion is that it doesn't make a huge difference: yes, your database of
names with ROB and ROBERT and ROBBIE won't compress the ROB part, but there
will be some magic convergence of strings in the ciphertext that wasn't
there before (less, but some). But my impression is that compression is the
big win on larger fields anyway, like comment fields and the like. And you
probably wouldn't FPE those because they're not structured by definition, so
there's not much win there. We do occasionally have customers who want to
encrypt, say, comment fields because "some of our reps put SSNs or PANs in
those even though they aren't supposed to"; but for those, another AES
encryption mode is a better choice anyway. Of course then you still lose
some compression!

 

Note also that in the case above (comment field with possible SSN/PAN)
another choice is to FPE just the digits. So:

Talked to John; he says his SSN is 123-45-6789, but file has 123-44-6789.

Might encrypt to:

Talked to John; he says his SSN is 761-64-3552, but file has 749-43-7477.

 

If they also had "Will call him back on the 13th", the "13" would also get
encrypted, of course. Kinda weird but it works.

 

Did I answer the question at all, or am I off in far left field?


--
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: Pervasive Encryption - why?

[Phil Smith III]

Timothy Sipples disagrees, which is his right, but the industry doesn't, so I'm 
not sure what else to say here.

 

.phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Phil Smith III]

Ron Hawkins wrote:

>That would be an improvement over a random cypher, but wouldn't the length

>and repeatability of the data patterns after encryption negatively affect

>LZW compression, along with deduplication?

 

Not sure I understand your question, but I'll try.

 

Length-is unchanged

 

Repeatability-XYZ encrypts to (perhaps) ABC consistently, so it's repeatable. 
But WXYZ does not encrypt to xABC, so is that what you mean about 
repeatability? Yes, that will affect compression to some extent. My suspicion 
is that it doesn't make a huge difference: yes, your database of names with ROB 
and ROBERT and ROBBIE won't compress the ROB part, but there will be some magic 
convergence of strings in the ciphertext that wasn't there before (less, but 
some). But my impression is that compression is the big win on larger fields 
anyway, like comment fields and the like. And you probably wouldn't FPE those 
because they're not structured by definition, so there's not much win there. We 
do occasionally have customers who want to encrypt, say, comment fields because 
"some of our reps put SSNs or PANs in those even though they aren't supposed 
to"; but for those, another AES encryption mode is a better choice anyway. Of 
course then you still lose some compression!

 

Note also that in the case above (comment field with possible SSN/PAN) another 
choice is to FPE just the digits. So:

Talked to John; he says his SSN is 123-45-6789, but file has 123-44-6789.

Might encrypt to:

Talked to John; he says his SSN is 761-64-3552, but file has 749-43-7477.

 

If they also had "Will call him back on the 13th", the "13" would also get 
encrypted, of course. Kinda weird but it works.

 

Did I answer the question at all, or am I off in far left field?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Ron Hawkins]

Phil,

FPE - I learn a bit more every day.

That would be an improvement over a random cypher, but wouldn't the length
and repeatability of the data patterns after encryption negatively affect
LZW compression, along with deduplication?

Ron


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Tuesday, 6 August 2019 23:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

Ron Hawkins wrote:

>One area where PE encryption, as implemented on z is where it is used

>together with compression. 

 

>The horse must go in front of the cart, meaning compression must happen

>before encryption, because it will be ineffective if you do it after. 

 

Not true with format-preserving data protection. Since the protected data
has the same format as the original, it should compress just as well. With
other forms of encryption, sure.

 

And yes, this is a well-integrated feature of PE encryption!


--
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: Pervasive Encryption - why?

[Timothy Sipples]

Phil Smith III wrote:
>I think you're missing one of my main points: "Substantial,
>real progress" isn't what data set encryption provides. It
>provides a LITTLE BIT of protection for a FEW minor attack
>vectors.

I disagree.

>Read about data-centric protection, note the analysts and
>standards bodies saying that container-level protection is
>just not very useful.

Let's suppose that's what they say. Who among them considers z/OS data sets
to be "containers"? Do they know what z/OS data sets are?

Data sets are files that contain one or more records. z/OS Data Set
Encryption is thus file-level encryption. (File system-level encryption is
different.) Which analysts and standards bodies characterize file-level
encryption as "just not very useful"?

By the way, applications don't generate, process, and control all data.
Middleware and systems generate, process, and control a great deal of data
too, including sensitive data. Moreover, data importance and sensitivity
are often unrelated or only loosely related to application context.
Applications (and their owners and users) don't necessarily understand the
sensitivity of the data they process any better than, say, storage
administrators and DBAs. For an interesting, recent, real world example,
see here:

https://theintercept.com/2018/01/29/strava-heat-map-fitness-tracker-us-military-base/

Application developers aren't perfect, and some of them are malicious. It
wouldn't be wise to rely solely on them to enforce a particular data
security posture.

All that said, I certainly wouldn't argue that application-level encryption
is "just not very useful." ALL levels of the "pyramid" are important.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Phil Smith III]

Timothy Sipples wrote:

>Even if you believe IBM caused some confusion -- I cannot find much

>evidence in the historical record of official IBM communications, but if

>that's what you believe -- that's certainly NOT a reason to add any more.

>I've asked you to help reduce terminology confusion, not to increase it.

>Thanks.

 

Never said it was official. I'm talking about how it was presented in the real 
world-at SHARE, IBM Z shows, and IBMers talking directly to customers-and how 
the customers have interpreted it. How am I adding more confusion by pointing 
out the confusion? Now I'm confused!

 

Fundamentally, I don't think we're disagreeing here, except that, again, I'm 
commenting on how the customers seem to be interpreting things, not how IBM 
officially wants them positioned. As I said, it has gotten better. But I've 
*heard* IBMers say "With PE [not "data set encryption", but that was the topic 
at hand) you're protected against attacks." And that's just not true. (Yes, 
they didn't *say* "all attacks", but nor did they qualify the statement 
explicitly.)

 

>We (the world) could wait at least a couple decades before application

>developers finish adding application-level encryption everywhere it's

>needed, assuming they even do that well and correctly (competently, without

>malice) and in a way that facilitates rapid progression to more secure

>algorithms as cryptography advances (big assumptions). But have you

>actually noticed what's going on in the real world? Substantial, real

>progress that doesn't require application changes has strong merit.

>Shouldn't this be obvious? The world cannot wait decades to rise to the

>many security challenges.

 

I think you're missing one of my main points: "Substantial, real progress" 
isn't what data set encryption provides. It provides a LITTLE BIT of protection 
for a FEW minor attack vectors. Worthwhile, because it's cheap. But 
"substantial"? No. Read about data-centric protection, note the analysts and 
standards bodies saying that container-level protection is just not very 
useful. And (to beat a dead horse) if folks think it's The Solution, it's 
perhaps worse than doing nothing, as they do it, solving a small part of the 
problem, and say "Well, that's done" and then won't discuss further steps to 
address the rest of the problem, because hey, it's done.

 

Re the pyramid: yes, we've been showing a version of that for a decade, and 
it's a useful illustration. IBM started doing so recently; that's a good thing. 
And yes, we solve that top part. But again, if you talk to IBM field folks and 
to customers, what we're hearing is not "application-level is the goal"; we're 
hearing "data set encryption [by whatever name] is cheap, easy, and solves the 
problem". Surely not all IBM field folks, but more than a few. That's what I'm 
irritated   about, on behalf of the customers.

 

I'm at SHARE this week, and just looked at SHARE session titles. It has gotten 
better: the last few SHAREs have used PE correctly. But if I go back further, 
it gets murkier. And in a SEC session I was just in, several people-including 
principals in the SEC project-in mentioning possible use of data set encryption 
for a ransomware attack, referred to it as "PE" and talked about "PE keys", 
again clearly meaning data set encryption [keys].

 

Bottom line: we've had customers tell us, "IBM says that PE [definitely meaning 
data set encryption] is sufficient to protect us". That doesn't mean IBM meant 
to say that, or even that a specific IBMer actually said that. But it is how 
the message was received.

 

Of course my perspective is colored by the fact that we're selling in this 
space. But that doesn't make the observations invalid; I've had conversations 
with other folks outside our company who have made the same observations.

 

Let me turn this around and ask: how do we reduce confusion if we don't 
acknowledge that it exists?

 

.phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Todd Arnold]

Correcting a couple of careless "n" and "m" typos in my previous post...
--
Another, similar approach that is sometimes used is to use "key shares" instead 
of components.  The difference is that with components, you must combine ALL of 
the components to form the master key, but with shares you only need a subset.  
This is typically called an m-of-n scheme, where you create n shares of the 
key, but any m of those can be combined to form the complete key.  This means 
that you do not need all of the n key share custodians to be present to load 
the master key - any m of them will do.  Note that Crypto Express does not 
support this for loading the master keys, but I wanted to include it here for 
completeness.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Todd Arnold]

The master keys, which are stored securely inside the Crypto Express HSM and 
can never be extracted, are the top-level keys in the key hierarchy.  Your 
application-level keys are stored outside the HSM, encrypted by the master 
keys.  Thus, if the HSM fails, you still have the externally-stored application 
keys, and all you need is to restore the master key into a new HSM card - then, 
all of those application keys will again be usable.
 
There are well-known and well-documented procedures for securely backing up and 
restoring the master keys.  In general, they follow the principles of 
dual-control and split-knowledge.  What this means is that the key value is 
mathematically broken into two or more separate values, such that none of those 
tells you anything at all about the value of the complete key.  You need to 
combine them in order to obtain the complete master key.  In most cases, the 
process that is used is to use "key components", which are sometimes called 
"key parts" - the components must all be exclusive-ored (XORed) together to 
form the master key, and that XOR only takes place inside the secure HSM card.  
Each component is protected by a separate person - a key component custodian - 
who keeps it safely locked up, and who enters it into the HSM when the master 
key must be loaded or restored.  The other key component custodian(s) do the 
same for their components, and the HSM creates the complete master key inside.  
The components can be manually keyed in (typically on the smart card reader of 
a TKE workstation), or they may be stored on electronically-readable media.  
The preferred method with Z and TKE is to have TKE store them on secure smart 
cards, and then read them out of those cards when needed.  With this approach, 
the key components are never outside a secure device in cleartext.
 
Another, similar approach that is sometimes used is to use "key shares" instead 
of components.  The difference is that with components, you must combine ALL of 
the components to form the master key, but with shares you only need a subset.  
This is typically called an m-of-n scheme, where you create n shares of the 
key, but any n of those can be combined to form the complete key.  This means 
that you do not need all of the m key share custodians to be present to load 
the master key - any n of them will do.  Note that Crypto Express does not 
support this for loading the master keys, but I wanted to include it here for 
completeness.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Mark Jacobs]

At $previousjob we had copies of the ICSF Master Encryption Keys stored in 
secure locations. During disaster recovery testing authorized people would 
re-enter those keys into the crypto-express hardware on that processor. One 
time we also lost a crypto-express card on our production machine. The working 
card handled all of our encryption/decryption processing and when the failed 
card was replaced, we had to enter the ICSF master keys into it before it was 
able to be used.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Wednesday, August 7, 2019 2:55 AM, Arthur  wrote:

> On 6 Aug 2019 07:59:59 -0700, in bit.listserv.ibm-main
> (Message-ID:lnxp265mb1484a20a9858d5a5271421bec7...@lnxp265mb1484.gbrp265.prod.outlook.com)
> lenni...@rsmpartners.com (Lennie Dymoke-Bradshaw) wrote:
>
> > Access to the ICSF CKDS would not be enough, as the keys
> > held there are encrypted (wrapped) using the master key.
> > The master key is held in the Crypto Express domain
> > corresponding to the LPAR in question. There is no
> > interface to extract the master key from the Crypto
> > Express device. The Crypto Express device is a FIPS 140-2
> > level 4 device so it will resist all sorts of attempts to
> > get at the master keys. It will destroy those keys before
> > you can get them out.
>
> Are you suggesting that if the Crypto Express device goes
> belly-up, that all encrypted data is forevermore
> unavailable? How does one decrypt during disaster testing
> or a real disaster?
>
> ---
>
> 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: Pervasive Encryption - why?

[Timothy Sipples]

Phil Smith III wrote:
>I feel that IBM inadvertently caused the confusion by calling
>the data set encryption "PE" at first: the fact that this
>thread refers to it as such actually supports that, no?

You've made this assertion a couple times now, and it's not actually true
as far as I can tell. IBM announced z/OS Data Set Encryption on February
21, 2017, in the z/OS 2.3 preview announcement. Refer to IBM Announcement
Letters 217-085.

Even if you believe IBM caused some confusion -- I cannot find much
evidence in the historical record of official IBM communications, but if
that's what you believe -- that's certainly NOT a reason to add any more.
I've asked you to help reduce terminology confusion, not to increase it.
Thanks.

>>Obviously IBM is not opposed to application-level encryption!
>>It's right there, at the top of the pyramid. Shouldn't you be
>>happy with that?
>I have seen that. I'm happy that IBM says that; I'd be happier
>if z/OS Data Set Encryption wasn't being touted as providing
>much more protection than it actually does. Doing so is not
>helping customers or IBM.

OK, I think that's pretty ridiculous.

We (the world) could wait at least a couple decades before application
developers finish adding application-level encryption everywhere it's
needed, assuming they even do that well and correctly (competently, without
malice) and in a way that facilitates rapid progression to more secure
algorithms as cryptography advances (big assumptions). But have you
actually noticed what's going on in the real world? Substantial, real
progress that doesn't require application changes has strong merit.
Shouldn't this be obvious? The world cannot wait decades to rise to the
many security challenges.

I don't know anybody at IBM (or elsewhere, for that matter) claiming that
z/OS Data Set Encryption is the *only* security-related capability that
customers should adopt. The "pyramid" certainly doesn't say that, and it's
a popular diagram by now. But it is quite important, and turning it on
doesn't require application changes.

We had a similar dialog in 2017 (or thereabouts), and you had the same
basic complaint as I recall. But I really don't know why you cannot point
to the "pyramid" -- happily so! -- and promote your particular product if
it has value to help add application-level encryption. "We solve this
part!" if that's what you do. What on earth is wrong with that? I don't get
it. Maybe you disagree with where particular customers are spending their
always finite resources first, but those are debates to have with your
prospective customers, surely and hopefully in a thoughtful, friendly way.
IBM, for its part, is clearly and repeatedly saying "application-level
encryption is important too." (Is the top of the "pyramid" a bad place?!?!)
How a particular customer prioritizes implementation of application-level
encryption, and where, is situational, of course.

My views are my own, as a reminder.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Arthur]

On 6 Aug 2019 07:59:59 -0700, in bit.listserv.ibm-main 
(Message-ID:) 
lenni...@rsmpartners.com (Lennie Dymoke-Bradshaw) wrote:


Access to the ICSF CKDS would not be enough, as the keys 
held there are encrypted (wrapped) using the master key. 
The master key is held in the Crypto Express domain 
corresponding to the LPAR in question. There is no 
interface to extract the master key from the Crypto 
Express device. The Crypto Express device is a FIPS 140-2 
level 4 device so it will resist all sorts of attempts to 
get at the master keys. It will destroy those keys before 
you can get them out.


Are you suggesting that if the Crypto Express device goes 
belly-up, that all encrypted data is forevermore 
unavailable? How does one decrypt during disaster testing 
or a real disaster? 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Phil Smith III]

Paul Gilmartin wrote, re FPE being ASCII-EBCDIC transparent:

>I'm astonished that's possible (but it can't be proven impossible).  Suppose I 
>change

>x'C1' to x'41' in the clear text (in fact, only a single bit change).  With 
>strong encryption

>that must change numerous bits in the encrypted text (ideally about half).  
>But IIRC

>you've said elsewhere that performing an EBCDIC=>ASCII translation, 
>byte-by-byte,

>on the encrypted text does the same for the decrypted text.

>(Can you cite an example?

 

Format-preserving data protection uses specific alphabets. So if "Paul" 
protects to "Abcd" in ASCII, "Paul" in EBCDIC protects to "Abcd" in EBCDIC. 
Thus you can translate "Abcd" from one encoding to the other and decrypt.

 

So obviously this means that a given FPE operation has to have an alphabet 
associated with it, and convert internally to a common format. For 7-bit 
US-ASCII and code page 1047, this is trivial. For other code pages, it's doable 
but requires a bit more work.

 

The excitement comes if you have a complex alphabet defined in UTF-8 land: say, 
a mixture of Cyrillic and Greek characters. In UTF-8, that works fine. But 
those are different EBCDIC code pages, sharing the same 256-byte space, so you 
*cannot* use such a format in EBCDIC-land. If you have an alphabet comprising 
*just* Cyrillic or *just* Greek, you can happily use that: convert EBCDIC input 
(which you of course must tell the system is the right Cyrillic or Greek code 
page) to UTF-8, encrypt or decrypt, convert back. Since a user cannot really 
have mixed Cyrillic and Greek data in a single EBCDIC field (at least, not 
without something VERY strange, with additional metadata), this works fine.

 

>(How about, e.g. IBM-1154<=>UTF-8?)

 

That's a Cyrillic page, yes? If ICONV/ICU handles the conversion, it's trivial. 
If not, then it's harder. But since any EBCDIC code page surely maps to UTF-8, 
I think it should work; it's only the other way that causes problems (10lb in 
5lb sack dept). 

 

I haven't mentioned DBCS, because I think it's pretty well dead. But I think 
ICONV and/or ICU on z/OS handle it; if so, it should also Just Work. Obviously 
I haven't tried it.

 

.phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Paul Gilmartin]

On Tue, 6 Aug 2019 00:42:48 -0400, Phil Smith III wrote:
>
>...; but more significantly, consider normal data flows: data moves between 
>ASCII and EBCDIC worlds, gets translated in the process. With whole-file, 
>non-format-preserving encryption, that means you have to decrypt, translate, 
>re-encrypt; with format-preserving, you don't have to add anything to that 
>flow. That's a big win when adding encryption to existing systems. For a new 
>system, of course, you'd design it differently.
>
I'm astonished that's possible (but it can't be proven impossible).  Suppose I 
change
x'C1' to x'41' in the clear text (in fact, only a single bit change).  With 
strong encryption
that must change numerous bits in the encrypted text (ideally about half).  But 
IIRC
you've said elsewhere that performing an EBCDIC=>ASCII translation, 
byte-by-byte,
on the encrypted text does the same for the decrypted text.

(Can you cite an example?)

(How about, e.g. IBM-1154<=>UTF-8?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Phil Smith III]

Joel C. Ewing pointed out that FPEd data won't compress quite as well as 
un-FPEd since repeated characters will not be repeated in the ciphertext. This 
is no doubt true, although some number of random repeats will occur in the 
ciphertext as well.

 

He wrote:

>Unless by format-preserving data protection you mean an encryption

>technique that preserves repeated characters (like blanks) and repeated

>combinations of characters, then NO, it will not compress well after

>encryption.



 

You're thinking whole-data set again, though; format-preserving data protection 
is not used on whole data sets, it's used on fields in structured data. So 
while yes, it will compress slightly less well, repeated occurrences of the 
same field will certainly match, and blanks are not usually part of the 
protected character set. (I'm talking about NIST-approved modes like FF1, BTW.)

 

So in your described case, compression will take a big hit; in an actual use 
case, not as much, although there will likely be some loss of compressibility.

 

Format-preserving data protection really involves a different way of thinking 
about data and data protection. I hate having to say that, as it sounds like 
marketing BS, but after more than eleven years of working with it, I have come 
to accept it.

 

.phsiii

 

P.S. This is a great discussion!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Joel C. Ewing]

On 8/6/19 8:38 AM, Phil Smith III wrote:
> Ron Hawkins wrote:
>
>> One area where PE encryption, as implemented on z is where it is used
>> together with compression. 
>  
>
>> The horse must go in front of the cart, meaning compression must happen
>> before encryption, because it will be ineffective if you do it after. 
>  
>
> Not true with format-preserving data protection. Since the protected data has 
> the same format as the original, it should compress just as well. With other 
> forms of encryption, sure.
>
>  
>
> And yes, this is a well-integrated feature of PE encryption!
>
Unless by format-preserving data protection you mean an encryption
technique that preserves repeated characters (like blanks) and repeated
combinations of characters, then NO, it will not compress well after
encryption.  An encryption technique that preserves repeated patterns is
basically a substitution cipher, which is highly insecure.  The meaning
of format-preserving is that it preserves the length and the
text/numeric attributes of a field, not that it preserves patterns of
repetition within or among fields.

Compression techniques work by recognizing repeated sequences within a
file and substituting a shorter value for a frequently occurring  longer
sequences.   A good encryption algorithm of necessity must obfuscate
repeated sequences.  Compression adds control fields, so if applied to a
file that has no or very few repeated sequences can even result in a
larger data file rather than a smaller one (try zipping a zipped file).

So, the compression step must be an integral front-end to the encryption
process, or it must be separately performed prior to encryption.

    Joel C Ewing

-- 
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Lennie Dymoke-Bradshaw]

Andrew,

Yes, from that same z/OS LPAR (or another in the same Sysplex), access to the 
keys via a RACF resource is also needed.

In order to access those keys one would need to use ICSF and the Crypto Express 
devices that hold the master keys for that domain/LPAR. So if another operating 
system (such as Linux) can work the interfaces to the Crypto Express and access 
the VSAM CKDS then they could gain access to the same services that ICSF uses. 

It would need to be IPLed into the exact same configuration as the z/OS system. 
It would need some work, but I guess it is possible in theory.

Access to the ICSF CKDS would not be enough, as the keys held there are 
encrypted (wrapped) using the master key. The master key is held in the Crypto 
Express domain corresponding to the LPAR in question. There is no interface to 
extract the master key from the Crypto Express device. The Crypto Express 
device is a FIPS 140-2 level 4 device so it will resist all sorts of attempts 
to get at the master keys. It will destroy those keys before you can get them 
out.

So the only thing that can be done is to use the interfaces the Crypto Express 
supplies to perform decryption of the data. 

The simplest way to achieve all this is to have another z/OS system which can 
be IPLed into that LPAR which has a rather more open set of RACF controls.

So I think physical access to the z processor would be required. 

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Andrew Rowley
Sent: 06 August 2019 12:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

On 5/08/2019 3:08 pm, Timothy Sipples wrote:
> Lennie Dymoke-Bradshaw wrote:
>> My first reason for PE for data sets is that encryption protects the 
>> data when it is accessed outside of its normal environment (i.e. not 
>> via the data's normal RACF environment).
> Some other examples, in no particular order: anything IPL'ed on the 
> system (or that could be) that isn't z/OS with its security manager 
> fully operating (e.g. ZZSA, standalone dump, Linux raw track access 
> mode, Linux zdsfs, z/VM, the Customized Offerings Driver), some of the 
> stuff Innovation Data Processing can do for backups, or a 
> misconfigured program properties table (NOPASS). RACF is excellent, 
> but you cannot assume it'll always be fully on guard.

Isn't RACF also required to protect the keys? What stops something else IPLed 
on the system from accessing the keys using the same interfaces z/OS uses?


Andrew Rowley

--
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: Pervasive Encryption - why?

[Phil Smith III]

Timothy Sipples 

>Phil, I don't think your assertion is true, but, regardless, what's the

>problem with granting another vendor the courtesy of referring to its

>products and offerings by the names they give them? If you're referring to

>z/OS Data Set Encryption, then use the name z/OS Data Set Encryption.

>Otherwise you're just trying to cause confusion, not reduce it.

 

Not my intention. I feel that IBM inadvertently caused the confusion by calling 
the data set encryption "PE" at first: the fact that this thread refers to it 
as such actually supports that, no? My intention was to reduce confusion, not 
cause it.

 

Hmm,, some Googling actually finds remarkably few hits for either:

"z/os" "data set encryption"

or 

"z/os" "pervasive encryption"

 

- fewer than 100 for either! That seems.weird and unexplainable; I'd've guessed 
that SHARE pages alone would have produced more than that?!

 

>As it happens, IBM includes application-level encryption as part of its

>Pervasive Encryption strategy. See, for example, Section 1.4.2 in this

>redbook (the "pyramid"):

>http://www.redbooks.ibm.com/redbooks/pdfs/sg248410.pdf

>Obviously IBM is not opposed to application-level encryption! It's right

>there, at the top of the pyramid. Shouldn't you be happy with that?

 

I have seen that. I'm happy that IBM says that; I'd be happier if z/OS Data Set 
Encryption wasn't being touted as providing much more protection than it 
actually does. Doing so is not helping customers or IBM.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Phil Smith III]

Ron Hawkins wrote:

>One area where PE encryption, as implemented on z is where it is used

>together with compression. 

 

>The horse must go in front of the cart, meaning compression must happen

>before encryption, because it will be ineffective if you do it after. 

 

Not true with format-preserving data protection. Since the protected data has 
the same format as the original, it should compress just as well. With other 
forms of encryption, sure.

 

And yes, this is a well-integrated feature of PE encryption!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Andrew Rowley]

On 5/08/2019 3:08 pm, Timothy Sipples wrote:

Lennie Dymoke-Bradshaw wrote:

My first reason for PE for data sets is that encryption
protects the data when it is accessed outside of its normal
environment (i.e. not via the data's normal RACF
environment).

Some other examples, in no particular order: anything IPL'ed on the system
(or that could be) that isn't z/OS with its security manager fully
operating (e.g. ZZSA, standalone dump, Linux raw track access mode, Linux
zdsfs, z/VM, the Customized Offerings Driver), some of the stuff Innovation
Data Processing can do for backups, or a misconfigured program properties
table (NOPASS). RACF is excellent, but you cannot assume it'll always be
fully on guard.


Isn't RACF also required to protect the keys? What stops something else 
IPLed on the system from accessing the keys using the same interfaces 
z/OS uses?



Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Timothy Sipples]

Phil Smith III wrote:
>(Note that I’m using the “Pervasive Encryption” term
>in the sense that IBM did when it was first introduced:
>the whole-data set encryption on z/OS. More recently
>they’ve expanded it to mean the entire IBM encryption
>strategy, which is still developing and not particularly
>integrated yet; Cameron’s question seemed to be entirely
>about the former, as were the replies.)

Phil, I don't think your assertion is true, but, regardless, what's the
problem with granting another vendor the courtesy of referring to its
products and offerings by the names they give them? If you're referring to
z/OS Data Set Encryption, then use the name z/OS Data Set Encryption.
Otherwise you're just trying to cause confusion, not reduce it.

As it happens, IBM includes application-level encryption as part of its
Pervasive Encryption strategy. See, for example, Section 1.4.2 in this
redbook (the "pyramid"):

http://www.redbooks.ibm.com/redbooks/pdfs/sg248410.pdf

Obviously IBM is not opposed to application-level encryption! It's right
there, at the top of the pyramid. Shouldn't you be happy with that?


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Ron Hawkins]

Phil,

One area where PE encryption, as implemented on z is where it is used
together with compression. 

The horse must go in front of the cart, meaning compression must happen
before encryption, because it will be ineffective if you do it after. 

It is a simple but important part of the implementation of data at rest, but
with PE extending to data in flight, I think it will have impacts on line
compression effectiveness.

While field-level encryption, given the small window, is less effective and
perhaps more costly than PE, I see PE on z being a less disruptive technique
where compression and encryption are sure to be performed in the right
sequence. 

Ron


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Tuesday, 6 August 2019 04:06
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

ITschak Mugzach wrote:

>PE is much cheaper, CPU wise, than a field level encryption as it use 
>bulk

>encryption. encrypting field by field is much more expensive and affect

>elapse as well.

 

Of course. That's part of the attraction. Yes, field-level is more
expensive. It's also more secure. And with format-preserving data
protection, you often don't need to decrypt to do processing, so it can be
essentially free for many use cases.

 

>I believe that what IBM is doing is to make the mainframe a file server.

>and this is the correct way to use the data. Don't move the entire

>dataset/database outside the mainframe and the ESM domain, but ask for 
>the

>data you need at the record and key levels. much like any other

>file/database server is used.

 

Also a fine idea. But that's not how IBM pushes the encryption, nor how
people use it (yet?).

 

>PE is not for those who have access to the data, from the local domain, 
>but

>to protect the access to data by other terms (shared dasd, backup, etc.).

 

Again, sure, but that isn't how IBM pushes it, nor how people think it will
protect them. That's the real problem: people think it solves problems it
doesn't.

 

.phsiii


--
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: Pervasive Encryption - why?

[Phil Smith III]

Lennie Dymoke-Bradshaw wrote, re platform-specificity:

>Why do you think this is platform specific? The AES encryption keys

>involved can be managed by an external key manager, (such as EKMF) and

>so those keys can be securely deployed to other (secured) platforms. The

>encrypted data can be read and then be sent to another platform and

>decrypted using the original encryption keys.

 

>Maybe I have misunderstood what you mean by "platform-specific".

 

Yeah, ok, I wasn't clear for sure. Sure, external keys being available across 
platforms is possible, if not common; but more significantly, consider normal 
data flows: data moves between ASCII and EBCDIC worlds, gets translated in the 
process. With whole-file, non-format-preserving encryption, that means you have 
to decrypt, translate, re-encrypt; with format-preserving, you don't have to 
add anything to that flow. That's a big win when adding encryption to existing 
systems. For a new system, of course, you'd design it differently.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Lennie Dymoke-Bradshaw]

Phil Smith said,
" It's also platform-specific, so when data has to be moved across platforms, 
it must be decrypted and (hopefully!) re-encrypted, which is both expensive and 
risky: those egress points provide huge attack surface."

Why do you think this is platform specific? The AES encryption keys involved 
can be managed by an external key manager, (such as EKMF) and so those keys can 
be securely deployed to other (secured) platforms. The encrypted data can be 
read and then be sent to another platform and decrypted using the original 
encryption keys.

Maybe I have misunderstood what you mean by "platform-specific".

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
'Dance like no one is watching. Encrypt like everyone is.'

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: 05 August 2019 17:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

Cameron Conacher asked about the value of PE, and various folks provided good 
answers. (Note that I'm using the "Pervasive Encryption" term in the sense that 
IBM did when it was first introduced: the whole-data set encryption on z/OS. 
More recently they've expanded it to mean the entire IBM encryption strategy, 
which is still developing and not particularly integrated yet; Cameron's 
question seemed to be entirely about the former, as were the replies.)

 

I'd add to those replies that this kind of "transparent" encryption is 
obviously appealing because of its ease of implementation and low overhead, but 
that beyond the specific use cases cited, it provides very little protection. 
While the SAF-level control provides a semblance of role-based access, it 
doesn't really, because it's not granular: there's no control within a data 
set. And that also means there's no real opportunity to alert on or throttle 
access based on usage patterns (UBA/UEBA 
 ).

 

It's also platform-specific, so when data has to be moved across platforms, it 
must be decrypted and (hopefully!) re-encrypted, which is both expensive and 
risky: those egress points provide huge attack surface.

 

GDPR and friends are all nascent in their interpretation. I find it very 
difficult to believe that one/three/five/whatever years from now, any of them 
will accept transparent encryption as an acceptable means of data protection, 
for the reasons above. PCI DSS (which is far more mature) has made it clear 
that transparent encryption is not the answer, and the security community 
agrees.

 

Note that I'm not suggesting that PE is useless, just that it's at best a 
partial solution. "We encrypted something" is not the same as "We're securing 
stuff".

 

The strongest encryption is field-level, application-level encryption. If it's 
also format-preserving, then you can also have cross-platform protection 
without having to decrypt/re-encrypt at the boundary. That's a pretty big win, 
for a number of reasons.

 

Disclosure: I've spent the last 11½ years on such a product, at Voltage and 
then HP/HPE/Micro Focus after acquisition. So I'm not exactly un-biased.

 

When considering encryption, the question I'd ask myself is, "Do I feel lucky?" 
no, wait, that's wrong. I mean, "What are the real threats I'm concerned about?"

 

Is it someone stealing a backup? Stealing a disk from an array? Sniffing the 
data on the wire between the array and the CEC? A rogue storage admin? Yay, PE 
will solve those. 

 

An actual breach? A rogue employee besides a storage admin? Data that gets 
copied to the distributed world without proper protection? PE won't help with 
any of those, I'm afraid.

 

Cameron also noted:

>I am just trying to find that corner case where someone you don't want 
>to have access, could possibly be able to gain access to the data when 
>the file is already protected with RACF?

 

This is a trenchant observation. If you look at any attack scenarios besides 
the ones cited (backups [who doesn't have encrypting tape already??], physical 
media theft [again, who doesn't have encrypting arrays?], sniffing the data on 
the wire [the original goal of PE], or a rogue storage admin [another real 
benefit, albeit one I doubt many folks were losing sleep over]), the encryption 
really isn't adding anything beyond a second SAF resource protecting the data. 
In other words, in those scenarios, the encryption is basically irrelevant: 
either you can read the data set (in which case you get it unencrypted) or you 
cannot. Same as any other SAF use case.

 

My biggest concern about PE is that folks hear "encryption" and go "yay, we do 
this and we're protected AND compliant". And the reality is that you mostly 
aren't.

-- 

...phsiii

 

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise

Distinguished Technologist
Micro Focus (Voltage)

Re: Pervasive Encryption - why?

[Phil Smith III]

ITschak Mugzach wrote:

>PE is much cheaper, CPU wise, than a field level encryption as it use bulk

>encryption. encrypting field by field is much more expensive and affect

>elapse as well.

 

Of course. That's part of the attraction. Yes, field-level is more expensive. 
It's also more secure. And with format-preserving data protection, you often 
don't need to decrypt to do processing, so it can be essentially free for many 
use cases.

 

>I believe that what IBM is doing is to make the mainframe a file server.

>and this is the correct way to use the data. Don't move the entire

>dataset/database outside the mainframe and the ESM domain, but ask for the

>data you need at the record and key levels. much like any other

>file/database server is used.

 

Also a fine idea. But that's not how IBM pushes the encryption, nor how people 
use it (yet?).

 

>PE is not for those who have access to the data, from the local domain, but

>to protect the access to data by other terms (shared dasd, backup, etc.).

 

Again, sure, but that isn't how IBM pushes it, nor how people think it will 
protect them. That's the real problem: people think it solves problems it 
doesn't.

 

.phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[ITschak Mugzach]

Phil,

PE is much cheaper, CPU wise, than a field level encryption as it use bulk
encryption. encrypting field by field is much more expensive and affect
elapse as well.

I believe that what IBM is doing is to make the mainframe a file server.
and this is the correct way to use the data. Don't move the entire
dataset/database outside the mainframe and the ESM domain, but ask for the
data you need at the record and key levels. much like any other
file/database server is used.

PE is not for those who have access to the data, from the local domain, but
to protect the access to data by other terms (shared dasd, backup, etc.).


ITschak

On Mon, Aug 5, 2019 at 7:07 PM Phil Smith III  wrote:

> Cameron Conacher asked about the value of PE, and various folks provided
> good answers. (Note that I’m using the “Pervasive Encryption” term in the
> sense that IBM did when it was first introduced: the whole-data set
> encryption on z/OS. More recently they’ve expanded it to mean the entire
> IBM encryption strategy, which is still developing and not particularly
> integrated yet; Cameron’s question seemed to be entirely about the former,
> as were the replies.)
>
>
>
> I’d add to those replies that this kind of “transparent” encryption is
> obviously appealing because of its ease of implementation and low overhead,
> but that beyond the specific use cases cited, it provides very little
> protection. While the SAF-level control provides a semblance of role-based
> access, it doesn’t really, because it’s not granular: there’s no control
> within a data set. And that also means there’s no real opportunity to alert
> on or throttle access based on usage patterns (UBA/UEBA <
> https://en.wikipedia.org/wiki/User_behavior_analytics/> ).
>
>
>
> It’s also platform-specific, so when data has to be moved across
> platforms, it must be decrypted and (hopefully!) re-encrypted, which is
> both expensive and risky: those egress points provide huge attack surface.
>
>
>
> GDPR and friends are all nascent in their interpretation. I find it very
> difficult to believe that one/three/five/whatever years from now, any of
> them will accept transparent encryption as an acceptable means of data
> protection, for the reasons above. PCI DSS (which is far more mature) has
> made it clear that transparent encryption is not the answer, and the
> security community agrees.
>
>
>
> Note that I’m not suggesting that PE is useless, just that it’s at best a
> partial solution. “We encrypted something” is not the same as “We’re
> securing stuff”.
>
>
>
> The strongest encryption is field-level, application-level encryption. If
> it’s also format-preserving, then you can also have cross-platform
> protection without having to decrypt/re-encrypt at the boundary. That’s a
> pretty big win, for a number of reasons.
>
>
>
> Disclosure: I’ve spent the last 11½ years on such a product, at Voltage
> and then HP/HPE/Micro Focus after acquisition. So I’m not exactly un-biased.
>
>
>
> When considering encryption, the question I’d ask myself is, “Do I feel
> lucky?” no, wait, that’s wrong. I mean, “What are the real threats I’m
> concerned about?”
>
>
>
> Is it someone stealing a backup? Stealing a disk from an array? Sniffing
> the data on the wire between the array and the CEC? A rogue storage admin?
> Yay, PE will solve those.
>
>
>
> An actual breach? A rogue employee besides a storage admin? Data that gets
> copied to the distributed world without proper protection? PE won’t help
> with any of those, I’m afraid.
>
>
>
> Cameron also noted:
>
> >I am just trying to find that corner case where someone you don't want to
> >have access, could possibly be able to gain access to the data when the
> >file is already protected with RACF?
>
>
>
> This is a trenchant observation. If you look at any attack scenarios
> besides the ones cited (backups [who doesn’t have encrypting tape
> already??], physical media theft [again, who doesn’t have encrypting
> arrays?], sniffing the data on the wire [the original goal of PE], or a
> rogue storage admin [another real benefit, albeit one I doubt many folks
> were losing sleep over]), the encryption really isn’t adding anything
> beyond a second SAF resource protecting the data. In other words, in those
> scenarios, the encryption is basically irrelevant: either you can read the
> data set (in which case you get it unencrypted) or you cannot. Same as any
> other SAF use case.
>
>
>
> My biggest concern about PE is that folks hear “encryption” and go “yay,
> we do this and we’re protected AND compliant”. And the reality is that you
> mostly aren’t.
>
> --
>
> ...phsiii
>
>
>
> Phil Smith III
> Senior Architect & Product Manager, Mainframe & Enterprise
>
> Distinguished Technologist
> Micro Focus (Voltage)
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 

Re: Pervasive Encryption - why?

[Phil Smith III]

Cameron Conacher asked about the value of PE, and various folks provided good 
answers. (Note that I’m using the “Pervasive Encryption” term in the sense that 
IBM did when it was first introduced: the whole-data set encryption on z/OS. 
More recently they’ve expanded it to mean the entire IBM encryption strategy, 
which is still developing and not particularly integrated yet; Cameron’s 
question seemed to be entirely about the former, as were the replies.)

 

I’d add to those replies that this kind of “transparent” encryption is 
obviously appealing because of its ease of implementation and low overhead, but 
that beyond the specific use cases cited, it provides very little protection. 
While the SAF-level control provides a semblance of role-based access, it 
doesn’t really, because it’s not granular: there’s no control within a data 
set. And that also means there’s no real opportunity to alert on or throttle 
access based on usage patterns (UBA/UEBA 
 ).

 

It’s also platform-specific, so when data has to be moved across platforms, it 
must be decrypted and (hopefully!) re-encrypted, which is both expensive and 
risky: those egress points provide huge attack surface.

 

GDPR and friends are all nascent in their interpretation. I find it very 
difficult to believe that one/three/five/whatever years from now, any of them 
will accept transparent encryption as an acceptable means of data protection, 
for the reasons above. PCI DSS (which is far more mature) has made it clear 
that transparent encryption is not the answer, and the security community 
agrees.

 

Note that I’m not suggesting that PE is useless, just that it’s at best a 
partial solution. “We encrypted something” is not the same as “We’re securing 
stuff”.

 

The strongest encryption is field-level, application-level encryption. If it’s 
also format-preserving, then you can also have cross-platform protection 
without having to decrypt/re-encrypt at the boundary. That’s a pretty big win, 
for a number of reasons.

 

Disclosure: I’ve spent the last 11½ years on such a product, at Voltage and 
then HP/HPE/Micro Focus after acquisition. So I’m not exactly un-biased.

 

When considering encryption, the question I’d ask myself is, “Do I feel lucky?” 
no, wait, that’s wrong. I mean, “What are the real threats I’m concerned about?”

 

Is it someone stealing a backup? Stealing a disk from an array? Sniffing the 
data on the wire between the array and the CEC? A rogue storage admin? Yay, PE 
will solve those. 

 

An actual breach? A rogue employee besides a storage admin? Data that gets 
copied to the distributed world without proper protection? PE won’t help with 
any of those, I’m afraid.

 

Cameron also noted:

>I am just trying to find that corner case where someone you don't want to
>have access, could possibly be able to gain access to the data when the
>file is already protected with RACF?

 

This is a trenchant observation. If you look at any attack scenarios besides 
the ones cited (backups [who doesn’t have encrypting tape already??], physical 
media theft [again, who doesn’t have encrypting arrays?], sniffing the data on 
the wire [the original goal of PE], or a rogue storage admin [another real 
benefit, albeit one I doubt many folks were losing sleep over]), the encryption 
really isn’t adding anything beyond a second SAF resource protecting the data. 
In other words, in those scenarios, the encryption is basically irrelevant: 
either you can read the data set (in which case you get it unencrypted) or you 
cannot. Same as any other SAF use case.

 

My biggest concern about PE is that folks hear “encryption” and go “yay, we do 
this and we’re protected AND compliant”. And the reality is that you mostly 
aren’t.

-- 

...phsiii

 

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise

Distinguished Technologist
Micro Focus (Voltage)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Timothy Sipples]

Lennie Dymoke-Bradshaw wrote:
>My first reason for PE for data sets is that encryption
>protects the data when it is accessed outside of its normal
>environment (i.e. not via the data's normal RACF
>environment).

Some other examples, in no particular order: anything IPL'ed on the system
(or that could be) that isn't z/OS with its security manager fully
operating (e.g. ZZSA, standalone dump, Linux raw track access mode, Linux
zdsfs, z/VM, the Customized Offerings Driver), some of the stuff Innovation
Data Processing can do for backups, or a misconfigured program properties
table (NOPASS). RACF is excellent, but you cannot assume it'll always be
fully on guard.

And it's not just "outside the normal environment." For example, it's
possible (and common) to mount remote NFS directories, with z/OS acting as
the NFS client. RACF might still be enforcing certain security controls
from its local z/OS point of view, but if the data are in the clear then
the NFS server at the other end is a weak link. Anybody who gets access to
the NFS server's drives/directories gets to read everything if it's
unencrypted. Roughly speaking this is "loosely attached DASD," and z/OS
supports that. Of course the whole point of NFS is often to share data in
certain, hopefully controlled ways across systems (including z/OS to z/OS),
and the network connections can be/should be encrypted if there's a hop
from the machine boundary. But what happens when someone decides to mount
an NFS directory, do their authorized processing using that form of disk
storage (to "escape" a chargeback?), such as backing up something
there...and then somebody else reads the data from the NFS server, or from
its backup? That'd be bad.

z/OS now supports cloud object storage via IBM Cloud Tape Connector for
z/OS and/or IBM DS8000 Transparent Cloud Tiering with z/OS DFSMShsm. It's a
good idea to encrypt there, too. The cloud object storage can be physically
located anywhere: within your data center(s), outside, or some of both.

There are "break glass" RACF storage administrator credentials available in
many shops, but even those emergency credentials shouldn't be able to
access most data.

Auditors shouldn't have access to most data either, although RACF has had
some improvements fairly recently to cater better to auditors, to allow
them to perform their important jobs but not to exceed them. z/OS Data Set
Encryption helps make sure the auditors stay within their lanes, too.

We should be a little careful (once again) to distinguish between z/OS Data
Set Encryption and Pervasive Encryption. They are related but distinct. In
this thread we're mostly discussing z/OS Data Set Encryption. Yes, please,
get z/OS Data Set Encryption turned on for everything it supports, and keep
expanding it. (z/OS 2.4 will introduce z/OS Data Set Encryption support for
yet more types, such as PDSEs.) Pervasive Encryption is broader, and yes,
you should make progress in the broader journey, too. For example, Coupling
Facility (CF) structure data encryption is another capability within
Pervasive Encryption strategy/architecture.

J.O.Skip Robinson wrote:
>For almost no cost, you can steer your company away
>from potentially disastrous litigation. Why would
>any management refuse that offer?

Relatedly, for almost no cost you can steer *yourself* (and other
administrators and operators) away from (many or most) potentially
disastrous data breach investigations and culpability. Do you even want the
ability to be able to read somebody else's data, such as your customers'?
Why would any IT professional want the personal risk of even being accused?


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Jesse 1 Robinson]

And I want to reiterate. For almost no cost, you can steer your company away 
from potentially disastrous litigation. Why would any management refuse that 
offer?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: Sunday, August 4, 2019 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Pervasive Encryption - why?

And the major reason, it easy and allmost cost nothing. I have a client in the 
us that encrypted almost anything /(short block sizes are not supported). He 
claims that on z14 box cpu is almost the same.

ITschak

בתאריך יום א׳, 4 באוג׳ 2019, 19:51, מאת Lennie Dymoke-Bradshaw ‏<
lenni...@rsmpartners.com>:

> Cameron,
>
> I missed this post the other day and I see many others have replied.
>
> My first reason for PE for data sets is that encryption protects the 
> data when it is accessed outside of its normal environment (i.e. not 
> via the data's normal RACF environment). So this includes removable 
> backups which are accessed away from your normal system. It covers 
> data extracted over PPRC links while being transferred to another 
> site. It also covers situations where production volumes may be 
> accessed from development LPARs or sysprog LPARs. This last case is 
> something I find at many sites. It is frequently justified in the name 
> of availability. I think if it was widely understood by auditors, they would 
> be raising a stink about it.
>
> My second reason is for compliance, whether that is to support GDPR, 
> PCI or whatever standard your installation is subject to. I have 
> always hoped that money spent on that compliance will actually improve 
> security.
>
> You may be interested in my paper on the backup of encrypted data.
> https://rsmpartners.com/News.Data-Backups-&-PE-Technical-Paper.html
>
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
>
> Email:lenni...@rsmpartners.com
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Cameron Conacher
> Sent: 03 August 2019 17:49
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Pervasive Encryption - why?
>
> Hello everyone,
> I have a curiousity question about Pervasive Encryption.
> If we are already protecting resources with RACF, what additional 
> benefit do we get from Pervasive Encryption? I think it is a good 
> idea, since encrypted data lets me sleep better. Pervasive Encryption 
> appears to be very simple to implement.
> My understanding (which may be incorrect) is that RACF will be used to 
> control encryption key access based on dataset profile rules and RACF rules.
> If a RACF ID does not have access to the encryption keys then they 
> cannot access the dataset.
> But at the same time, if a RACF ID does not have access to the 
> dataset, they cannot access it.
>
> So, if the underlying file is encrypted, what addition security is in 
> place?
> Maybe if someone breaks into the data centre and steals the disk drives?
>
> If a hacker gets a RACF ID, and the RACF ID allows them to access the 
> dataset, then they can read the data.
> But, isn't that where we are today? No RACF ID = no access.
>
> Obviously I am missing something here.
>
> --
> 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[ITschak Mugzach]

And the major reason, it easy and allmost cost nothing. I have a client in
the us that encrypted almost anything /(short block sizes are not
supported). He claims that on z14 box cpu is almost the same.

ITschak

בתאריך יום א׳, 4 באוג׳ 2019, 19:51, מאת Lennie Dymoke-Bradshaw ‏<
lenni...@rsmpartners.com>:

> Cameron,
>
> I missed this post the other day and I see many others have replied.
>
> My first reason for PE for data sets is that encryption protects the data
> when it is accessed outside of its normal environment (i.e. not via the
> data's normal RACF environment). So this includes removable backups which
> are accessed away from your normal system. It covers data extracted over
> PPRC links while being transferred to another site. It also covers
> situations where production volumes may be accessed from development LPARs
> or sysprog LPARs. This last case is something I find at many sites. It is
> frequently justified in the name of availability. I think if it was widely
> understood by auditors, they would be raising a stink about it.
>
> My second reason is for compliance, whether that is to support GDPR, PCI
> or whatever standard your installation is subject to. I have always hoped
> that money spent on that compliance will actually improve security.
>
> You may be interested in my paper on the backup of encrypted data.
> https://rsmpartners.com/News.Data-Backups-&-PE-Technical-Paper.html
>
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
>
> Email:lenni...@rsmpartners.com
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Cameron Conacher
> Sent: 03 August 2019 17:49
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Pervasive Encryption - why?
>
> Hello everyone,
> I have a curiousity question about Pervasive Encryption.
> If we are already protecting resources with RACF, what additional benefit
> do we get from Pervasive Encryption? I think it is a good idea, since
> encrypted data lets me sleep better. Pervasive Encryption appears to be
> very simple to implement.
> My understanding (which may be incorrect) is that RACF will be used to
> control encryption key access based on dataset profile rules and RACF rules.
> If a RACF ID does not have access to the encryption keys then they cannot
> access the dataset.
> But at the same time, if a RACF ID does not have access to the dataset,
> they cannot access it.
>
> So, if the underlying file is encrypted, what addition security is in
> place?
> Maybe if someone breaks into the data centre and steals the disk drives?
>
> If a hacker gets a RACF ID, and the RACF ID allows them to access the
> dataset, then they can read the data.
> But, isn't that where we are today? No RACF ID = no access.
>
> Obviously I am missing something here.
>
> --
> 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: Pervasive Encryption - why?

[Lennie Dymoke-Bradshaw]

Cameron,

I missed this post the other day and I see many others have replied.

My first reason for PE for data sets is that encryption protects the data when 
it is accessed outside of its normal environment (i.e. not via the data's 
normal RACF environment). So this includes removable backups which are accessed 
away from your normal system. It covers data extracted over PPRC links while 
being transferred to another site. It also covers situations where production 
volumes may be accessed from development LPARs or sysprog LPARs. This last case 
is something I find at many sites. It is frequently justified in the name of 
availability. I think if it was widely understood by auditors, they would be 
raising a stink about it.

My second reason is for compliance, whether that is to support GDPR, PCI or 
whatever standard your installation is subject to. I have always hoped that 
money spent on that compliance will actually improve security.

You may be interested in my paper on the backup of encrypted data.
https://rsmpartners.com/News.Data-Backups-&-PE-Technical-Paper.html

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  

Email:            lenni...@rsmpartners.com
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Cameron Conacher
Sent: 03 August 2019 17:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Pervasive Encryption - why?

Hello everyone,
I have a curiousity question about Pervasive Encryption.
If we are already protecting resources with RACF, what additional benefit do we 
get from Pervasive Encryption? I think it is a good idea, since encrypted data 
lets me sleep better. Pervasive Encryption appears to be very simple to 
implement.
My understanding (which may be incorrect) is that RACF will be used to control 
encryption key access based on dataset profile rules and RACF rules.
If a RACF ID does not have access to the encryption keys then they cannot 
access the dataset.
But at the same time, if a RACF ID does not have access to the dataset, they 
cannot access it.

So, if the underlying file is encrypted, what addition security is in place?
Maybe if someone breaks into the data centre and steals the disk drives?

If a hacker gets a RACF ID, and the RACF ID allows them to access the dataset, 
then they can read the data.
But, isn't that where we are today? No RACF ID = no access.

Obviously I am missing something here.

--
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: Pervasive Encryption - why?

[Cameron Conacher]

Thanks everyone.
That certainly helps.

On Sat, Aug 3, 2019 at 4:31 PM Charles Mills  wrote:

> Others have mentioned backups. The real value is in the right to *do*
> backups. Your storage administrator may have access to the dataset, but not
> the decryption key. So he can do backups, but he can't steal credit card
> numbers or health information.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: Saturday, August 3, 2019 12:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Pervasive Encryption - why?
>
> Hello everyone,
> I have a curiousity question about Pervasive Encryption.
> If we are already protecting resources with RACF, what additional benefit
> do we get from Pervasive Encryption? I think it is a good idea, since
> encrypted data lets me sleep better. Pervasive Encryption appears to be
> very simple to implement.
> My understanding (which may be incorrect) is that RACF will be used to
> control encryption key access based on dataset profile rules and RACF
> rules.
> If a RACF ID does not have access to the encryption keys then they cannot
> access the dataset.
> But at the same time, if a RACF ID does not have access to the dataset,
> they cannot access it.
>
> So, if the underlying file is encrypted, what addition security is in
> place?
> Maybe if someone breaks into the data centre and steals the disk drives?
>
> If a hacker gets a RACF ID, and the RACF ID allows them to access the
> dataset, then they can read the data.
> But, isn't that where we are today? No RACF ID = no access.
>
> Obviously I am missing something here.
>
> --
> 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: Pervasive Encryption - why?

[Charles Mills]

Others have mentioned backups. The real value is in the right to *do* backups. 
Your storage administrator may have access to the dataset, but not the 
decryption key. So he can do backups, but he can't steal credit card numbers or 
health information.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cameron Conacher
Sent: Saturday, August 3, 2019 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Pervasive Encryption - why?

Hello everyone,
I have a curiousity question about Pervasive Encryption.
If we are already protecting resources with RACF, what additional benefit
do we get from Pervasive Encryption? I think it is a good idea, since
encrypted data lets me sleep better. Pervasive Encryption appears to be
very simple to implement.
My understanding (which may be incorrect) is that RACF will be used to
control encryption key access based on dataset profile rules and RACF rules.
If a RACF ID does not have access to the encryption keys then they cannot
access the dataset.
But at the same time, if a RACF ID does not have access to the dataset,
they cannot access it.

So, if the underlying file is encrypted, what addition security is in place?
Maybe if someone breaks into the data centre and steals the disk drives?

If a hacker gets a RACF ID, and the RACF ID allows them to access the
dataset, then they can read the data.
But, isn't that where we are today? No RACF ID = no access.

Obviously I am missing something here.

--
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: Pervasive Encryption - why?

[Steve Smith]

There are some good presentations on SHARE about this.  The point about
backups is that the backups are made of the encrypted file, by personnel
and software that do *not* have the access to the decryption key.  That
allows admins & sysprogs to manage storage & such without having the
ability to actually read the data.  And any copies or backups are secure.

Users & systems that do have the authorization to decrypt and access the
data are responsible for not compromising that access.  That's no different
with pervasive encryption.  Making unencrypted copies would pretty much
destroy the usefulness of pervasive encryption.  So presumably (hopefully)
you have other controls to stop users from doing that.

Anyway, it's a piece of the puzzle.

sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Jesse 1 Robinson]

The protective side of data security is only half technical. The other half is 
GDPR (General Data Protection Regulation), a set of controls that spell out 
Draconian penalties for any entity that allows--or presides over--a data breach 
affecting EU citizens. The hair-raising penalties are more or less forgiven if 
the stolen data is encrypted. There is no consideration in the regulations for 
software or hardware security mechanisms such as SAF (RACF, ACF2, TSS) . That 
makes pervasive encryption hugely valuable. If data is breached, it will be 
presumably useless to the perpetrator. You can't hire enough lawyers to equal 
that advantage. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Saturday, August 3, 2019 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Pervasive Encryption - why?

One use case is backups.  If someone can access a backup outside of the 
controls the system it resides on employs they could not compromise the data.  
Consider potential data services that host backups offsite for instance.  Your 
protecting your data while entrusting someone with ensuring its available

That’s a strong use case I think

Matt Hogstrom
+1 (919) 656-0564

> On Aug 3, 2019, at 12:48, Cameron Conacher  wrote:
> 
> Hello everyone,
> I have a curiousity question about Pervasive Encryption.
> If we are already protecting resources with RACF, what additional 
> benefit do we get from Pervasive Encryption? I think it is a good 
> idea, since encrypted data lets me sleep better. Pervasive Encryption 
> appears to be very simple to implement.
> My understanding (which may be incorrect) is that RACF will be used to 
> control encryption key access based on dataset profile rules and RACF rules.
> If a RACF ID does not have access to the encryption keys then they 
> cannot access the dataset.
> But at the same time, if a RACF ID does not have access to the 
> dataset, they cannot access it.
> 
> So, if the underlying file is encrypted, what addition security is in place?
> Maybe if someone breaks into the data centre and steals the disk drives?
> 
> If a hacker gets a RACF ID, and the RACF ID allows them to access the 
> dataset, then they can read the data.
> But, isn't that where we are today? No RACF ID = no access.
> 
> Obviously I am missing something here.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Cameron Conacher]

Hello Matt,
I am not sure about backups.
This is Pervasive Encryption.
So, again my understanding is that IF your RACFID can access the file, you
will read the data and it will be presented to you as unencrypted.
Now, if you write it to DASD and encryption is on for that device it will
be encrypted, otherwise not encrypted.
And if you write it to TAPE, then it depends what your tape systems does.

I am just trying to find that corner case where someone you don't want to
have access, could possibly be able to gain access to the data when the
file is already protected with RACF? I cannot see a blackhat breaking into
the mainframe. If they did manage that, I cannot see them bypassing RACF.
If they did, manage to get by RACF, then regardless of whether or not the
file was encrypted, they ought to be able to read it, since they have
somehow gotten RACF access.
Same is true for an internal compromise. If you can get RACF access to the
file, it will not matter whether or not the data is encrypted.
Maybe I am missing something.
Physically taking a drive is the only one I have come up with so far.

I like the idea of encryption.
If we decommission a drive and somehow it ends up on eBay, the data is
useless.
But, there would need to be a lot of processes that are ignored/bypassed to
get that far.


On Sat, Aug 3, 2019 at 1:25 PM Matt Hogstrom  wrote:

> One use case is backups.  If someone can access a backup outside of the
> controls the system it resides on employs they could not compromise the
> data.  Consider potential data services that host backups offsite for
> instance.  Your protecting your data while entrusting someone with ensuring
> its available
>
> That’s a strong use case I think
>
> Matt Hogstrom
> +1 (919) 656-0564
>
> > On Aug 3, 2019, at 12:48, Cameron Conacher  wrote:
> >
> > Hello everyone,
> > I have a curiousity question about Pervasive Encryption.
> > If we are already protecting resources with RACF, what additional benefit
> > do we get from Pervasive Encryption? I think it is a good idea, since
> > encrypted data lets me sleep better. Pervasive Encryption appears to be
> > very simple to implement.
> > My understanding (which may be incorrect) is that RACF will be used to
> > control encryption key access based on dataset profile rules and RACF
> rules.
> > If a RACF ID does not have access to the encryption keys then they cannot
> > access the dataset.
> > But at the same time, if a RACF ID does not have access to the dataset,
> > they cannot access it.
> >
> > So, if the underlying file is encrypted, what addition security is in
> place?
> > Maybe if someone breaks into the data centre and steals the disk drives?
> >
> > If a hacker gets a RACF ID, and the RACF ID allows them to access the
> > dataset, then they can read the data.
> > But, isn't that where we are today? No RACF ID = no access.
> >
> > Obviously I am missing something here.
> >
> > --
> > 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: Pervasive Encryption - why?

[Paul Gilmartin]

On Sat, 3 Aug 2019 13:24:46 -0400, Matt Hogstrom wrote:

>One use case is backups.  If someone can access a backup outside of the 
>controls the system it resides on employs they could not compromise the data.  
>Consider potential data services that host backups offsite for instance.  Your 
>protecting your data while entrusting someone with ensuring its available

>> On Aug 3, 2019, at 12:48, Cameron Conacher wrote:
>> ...
>> So, if the underlying file is encrypted, what addition security is in place?
>> Maybe if someone breaks into the data centre and steals the disk drives?
>> 
Or, compromises a communication channel to remote storage.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Pervasive Encryption - why?

[Matt Hogstrom]

One use case is backups.  If someone can access a backup outside of the 
controls the system it resides on employs they could not compromise the data.  
Consider potential data services that host backups offsite for instance.  Your 
protecting your data while entrusting someone with ensuring its available

That’s a strong use case I think

Matt Hogstrom
+1 (919) 656-0564

> On Aug 3, 2019, at 12:48, Cameron Conacher  wrote:
> 
> Hello everyone,
> I have a curiousity question about Pervasive Encryption.
> If we are already protecting resources with RACF, what additional benefit
> do we get from Pervasive Encryption? I think it is a good idea, since
> encrypted data lets me sleep better. Pervasive Encryption appears to be
> very simple to implement.
> My understanding (which may be incorrect) is that RACF will be used to
> control encryption key access based on dataset profile rules and RACF rules.
> If a RACF ID does not have access to the encryption keys then they cannot
> access the dataset.
> But at the same time, if a RACF ID does not have access to the dataset,
> they cannot access it.
> 
> So, if the underlying file is encrypted, what addition security is in place?
> Maybe if someone breaks into the data centre and steals the disk drives?
> 
> If a hacker gets a RACF ID, and the RACF ID allows them to access the
> dataset, then they can read the data.
> But, isn't that where we are today? No RACF ID = no access.
> 
> Obviously I am missing something here.
> 
> --
> 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