IBM Z and LinuxONE IBM Z

IBM Z

The enterprise platform for mission-critical applications brings next-level data privacy, security, and resiliency to your hybrid multicloud.

 View Only

  • 1.  Encryption & Virtual Data

    Posted Tue December 31, 2019 09:20 AM
    Can a pervasively encrypted z series share virtual data with a subsidiary (e.g, edge) server without having to download the data? If it could (or resorted to download) for use on the subsidiary, could it be decrypted fast enough on it to be of use in transaction work?
    Terry
    ------------------------------------------------------------------------------
    regards,
    Dr Terry Critchley (ex-IBM)  +44 7902269856


    "You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete." - Buckminster Fuller







  • 2.  RE: Encryption & Virtual Data

    Posted Thu January 02, 2020 09:41 AM
    Hi Terry.  I'm not sure I completely understand your question but let me take a stab at it to at least start the conversation.

    Data that is encrypted on Z can be "shared" just like data that is unencrypted.  The operating system on Z (ex: z/OS) will decrypt the file when it accesses it, before it hands the data off to whatever process is accessing it.

    Data needs to be decrypted for processing.  Let's look at a sample use case for clarification.  Let's say data is stored in a Db2 database on z/OS and we do some processing with that data on a cell phone.  The data is encrypted by z/OS when Db2 writes it to disk.  When the user accesses it via mobile device, Db2 asks z/OS to read the data and z/OS decrypts it for Db2 which then sends it to the mobile device.  Of course it could be re-encypted during transport by something like AT-TLS.

    Can Z can keep up with the demands of timely transactions given this encryption?  Yes, in fact Z is built for this sort of thing -- some call it a crypto beast.  This is accomplished by on-CPU crypto coprocessors and I/O (Crypto Express) cards.

    Does this help?

    ------------------------------
    Matthew Cousens
    ------------------------------

    Original Message


  • 3.  RE: Encryption & Virtual Data

    Posted Fri January 03, 2020 09:12 AM
    (Matthew, I think I can help "translate" what you said into terms of what Terry asked -- at least, let's see if I can.)
    Terry, let me rephrase/simplify your question a little bit first -- ignoring pervasive encryption, can your edge server directly access the z Series disk array and directly read the (unencrypted) data stored on it?  If it can -- then you probably can not use pervasive encryption on that dataset or HFS or other file structure, because if it were encrypted, only the mainframe would have access to the keys to decrypt that data in order to process it.  (This is not to say that the data array can't use internal hardware encryption to protect the media, and that would decrypt data -- but pervasive encryption causes only Encrypted data to be stored on the array, which would be doubly encrypted by the array hardware as well.)

    So what Matthew described is what I believe you consider to be "downloading the data" -- you either need to use a file transfer of some kind (like FTPS or SFTP or NDM or whatever) to copy the data to your edge server (and the pervasive encryption would decrypt the data before the transfer happens); or you need to access the data needed via some sort of API or Web Service or DB2 service that would select the data requested (decrypting it along the way) and handing it to the requester.  And, as he said, it is fast enough to provide the decrypted data to your edge server for it to provide transactional processing.

    So the short answer is, once pervasively encrypted, you must use some sort of z series access service to "download" the data to your edge server to access the data, and it should be able to do that fast enough for you.  You won't be able to directly access the data array and get the data while encrypted.  (Your mileage may vary...)

    ------------------------------
    Scott Tietjen CISSP
    ------------------------------

    Original Message


  • 4.  RE: Encryption & Virtual Data

    Posted Fri January 03, 2020 01:59 PM
    "Data needs to be decrypted for processing" -- not necessarily. This is where technologies such as Format-Preserving Encryption can provide data-centric security, often allowing processing of data in its encrypted state, requiring minimal decryption, only at the boundaries. And IBM Z is of course a fine platform for this. Note also that format-preserving data protection means that existing data flows that translate between ASCII and EBCDIC can do so *on the protected data*, again increasing security and reducing the need for decryption until absolutely necessary.


    While the data set-level protection provided by pervasive encryption is beneficial, the fact that the data is always decrypted on access is suboptimal from a security standpoint, as it means there is cleartext available in more cases than required. Persistent, data-centric security is the ideal--and is achievable today.



    ------------------------------
    Phil Smith III
    ------------------------------

    Original Message


  • 5.  RE: Encryption & Virtual Data

    Posted Mon January 06, 2020 08:46 AM
    the dataset is not always decrypted on access, it would be only if you have an authorization ID that has access to the key label that was used to encrypt it, and the key label is protected by RACF or other others tools that do the same thing (and this is optional, its possible to have key labels with them being secured). if you dont have access, you cant decrypt it. and since that key label is hardware specific (as an example changing from a Z13 to a Z14) will require some changes to allow the new hardware to access it. is this perfect? of course not, as some one could break into the system, and gain access to the data. it just might be harder to do than in other systems if you can and do encrypt Z/OS config data also.  And it still will require vigilance to make sure that unauthorized people dont have access to the data, and that authorized people can.

    ------------------------------
    David Williams
    ------------------------------

    Original Message


  • 6.  RE: Encryption & Virtual Data

    Posted Mon January 06, 2020 09:57 AM

    David,

    Assuming we're talking about z/OS data set encryption, the only way to fetch the data without decryption is if you're a storage administrator. So all the data set encryption really protects against is:
    1) Media theft
    2) Rogue storage admins

    Otherwise, it's just adding another SAF resource protecting the data: the actual encryption isn't providing any protection, since any other access to the data implies automatic, transparent decryption.

    As I said, that doesn't make it useless--but it does mean that folks need to understand what it is and isn't protecting against. Data-centric protection is both more fine-grained and more pervasive, and as I wrote, often means that the data can be processed in its protected state.

    Here's an example: an SSN. When do you (or your systems) care exactly what someone's SSN is? If you're verifying it, you should be protecting the value you're checking and comparing it to the protected value, not decrypting the protected value for comparison. Any other likely use within the enterprise is similar: it doesn't care what the value is, just that it's unique and consistent. The only time you likely need to decrypt is at the boundary, when passing the data to another entity (e.g., IRS, or one of the CRAs for a credit check). With a data-centric approach, the philosophy is "protect early, decrypt rarely", so many applications never see cleartext. This is clearly more secure, reduces audit scope, etc.

    It's also a big mindshift: we tend to think along the lines of what Terry wrote, that the data must be decrypted for any use to occur. Once you get your head around the fact that this need not be true, it's easy to see the greater benefits of data-centric protection.



    ------------------------------
    Phil Smith III
    ------------------------------

    Original Message


Related Content