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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to