R.S. asked: >BTW: What's wrong with whole disk encryption? Why field-level encryption is >better? IMHO it addresses different needs.
Arye Shemer wrote: >First I 'll try to explain the reasoning behind my request. >1. Encryption of 'Data In Rest' is a requirement by local PCI regulation >2. Encryption of 'Data In Rest' is just one step (in probably of many) of >data protection required by this regulation >3. Field encryption by DB2 is good solution but it does not covers files or >reports (sysouts) which require another solution >4. Disk encryption is probaly the best and simple solution for encryption >of 'Data In Rest' , but (there always are some buts) > If you do not have disks which are encryption enable you have to buy >them, it might be expensive >So we thought that in order to comply with the regulation requirements >we'll use (if exist) some device which encrypt/decrypt >the data going/coming from the disks. R.S.: Right. But I suspected (and Arye has confirmed) that this was PCI or other regulation-driven. There are a couple of problems with whole-disk encryption for regulatory compliance: 1) Lack of Separation of Duties controls: since it's all-or-nothing, it's not really possible to say "This user can see THIS data, but not THAT data" using the encryption as a control. So now you have to add MORE controls. 2) Weaker security in terms of attack points. If you think of a stack, bottom to top, of hardware/OS(filesystem)/database/middleware/application, and think about encryption applied at each of those levels, each only protects the levels BELOW it. So if you encrypt at the application level, you're providing the most security: an attacker has to break the application to get at the real data. At the other extreme (hardware), all they need to break into is the machine. And so forth. Ron Hawkins noted: >I don't have any problem with field, record or file level encryption, but >there is a downside if you are doing remote copy over a network, as it >encrypted data usually compresses very poorly. It's not a problem for >everyone. Warning: Voltage-specific information follows. If you encrypt to binary, true. If you use Format-Preserving Encryption technology, the output looks like the input, and thus compresses just fine. AES FFX mode<http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html> (in final stages of NIST approval as an official mode of AES) provides this. Provably secure, vetted by third parties, etc. (hence NIST's willingness to adopt it as a standard). For z/OS, we have a number of native solutions, providing both Format-Preserving Encryption and Secure Stateless Tokenization technologies through the same API, with proper z/OS-style centralized control, ESM integration, etc. -- ...phsiii Phil Smith III p...@voltage.com<mailto:p...@voltage.com> Voltage Security, Inc. www.voltage.com<http://www.voltage.com/> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
