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: Using Google Chrome to open IBM z/OS 2.4 Library Index ???

[Jon Perryman]

 Sorry for the late reply. I just saw this question.
If you have questions about chrome browser, ask them in the google group 
chromium-discuss. In fact, questions about any chromium based browser (e.g. 
chrome, MS Edge and several others) can be asked here. Don't confuse 
chromium-os with chromium (people often refer to both as chromium which have 
different news groups).
For security reasons, Chrome does not support Windows file extensions. This is 
a huge security exposure with other browsers  (e.g. MS Word autorun script).
There are very few extensions that chrome supports (e.g. PDF) and  they use 
very specific low risk programs (not acrobat) to reduce the risk. It's very 
unlikely they will support file extensions. They may in a few years support PDX 
files but who knows.
Sorry for the bad news but this is the biggest reason I use chrome.
Jon.On Wednesday, July 24, 2019, 07:24:34 AM PDT, Lionel B Dyck 
 wrote:  
 
 When using Google Chrome with a bookmark to the .pdx for the z/OS library,
the pdx opens as a text file.

 

It opens in Adobe Reader just fine using Edge when bookmarked.

 

Any suggestions on how to 'fix' Chrome?  

--
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: Getting ABEND reason code from attached subtask

[Seymour J Metz]

Has all IBM code that issues an ABEND documented to give a reason code been 
updated to use the REASON keyword rather than just loading R15 before the ABEND?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Sunday, August 4, 2019 7:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting ABEND reason code from attached subtask


what about the normal completion reason code (R0)?

"Normal completion reason code" is not a concept supported by z/OS. Of
course there is "value in R0 upon normal completion" but that is not
surfaced.

The TCB/STCB has the information that is available. Since you attached
with ECB the TCB/STCB still remain, until you DETACH.
STCBCMP/STCBCMPC is the best field for the return code (whether normal or
abnormal completion).
TCBARC has the abend reason code when bit TCBRV316 is on (looks like no
one ever noticed the need to provide a suitable name for that bit, since
it is never set directly in the code -- the abend macro ends up setting
the bit into the high byte of the abend code). This is defined only for an
abend event. I don't think the RB chain is intact at the time you are
looking, so I don't think you can find the regs from
time-of-normal-completion unless they're in the TCBGRSx fields (I did not
check, but that seems very unlikely).  It appears that TCBARC will have
the value from the abend's R15 whether or not REASON was specified, but
TCBRV316 will be off if REASON was not specified.


At ABEND, R15 contains the REASON.

To be picky, that is true only when the ABEND was issued with the REASON
keyword. Otherwise, R15 contains a value that might or might not be
considered a reason by the ABEND invoker.


you can check the ABTERM flag in the subtask's TCB.

The intended way to tell is now (and has been for quite a while)
TcbEndingAbnormally (see the comments for STCBCMP).


Peter Relson
z/OS Core Technology Design


--
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]

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: Getting ABEND reason code from attached subtask

[Kirk Wolf]

Thanks everyone!


On Sun, Aug 4, 2019 at 6:55 AM Peter Relson  wrote:

> 
> what about the normal completion reason code (R0)?
> 
> "Normal completion reason code" is not a concept supported by z/OS. Of
> course there is "value in R0 upon normal completion" but that is not
> surfaced.
>
> The TCB/STCB has the information that is available. Since you attached
> with ECB the TCB/STCB still remain, until you DETACH.
> STCBCMP/STCBCMPC is the best field for the return code (whether normal or
> abnormal completion).
> TCBARC has the abend reason code when bit TCBRV316 is on (looks like no
> one ever noticed the need to provide a suitable name for that bit, since
> it is never set directly in the code -- the abend macro ends up setting
> the bit into the high byte of the abend code). This is defined only for an
> abend event. I don't think the RB chain is intact at the time you are
> looking, so I don't think you can find the regs from
> time-of-normal-completion unless they're in the TCBGRSx fields (I did not
> check, but that seems very unlikely).  It appears that TCBARC will have
> the value from the abend's R15 whether or not REASON was specified, but
> TCBRV316 will be off if REASON was not specified.
>
> 
> At ABEND, R15 contains the REASON.
> 
> To be picky, that is true only when the ABEND was issued with the REASON
> keyword. Otherwise, R15 contains a value that might or might not be
> considered a reason by the ABEND invoker.
>
> 
> you can check the ABTERM flag in the subtask's TCB.
> 
> The intended way to tell is now (and has been for quite a while)
> TcbEndingAbnormally (see the comments for STCBCMP).
>
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> 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