> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of John Mattson
> Sent: Tuesday, September 05, 2006 3:23 PM
> To: [email protected]
> Subject: Encrypting tape drives... anyone considering field
> encryption?
>
>
> Encrypting everything which goes out of the data center is
> expensive and/or uses lots of resources (same thing really),
> takes time,
> and complicates your disaster recovery. In addition none of these
> "encrypt all tape" solutions deals with threats inside the
> company, either
> employees, or hackers.
> So what's a better solution?
> Just how much data really NEEDS encryption? I submit
> for most
> businesses (eg. not financial institutions), very little.
> Credit card
> numbers, and perhaps, names. If names are encrypted everything else,
> address, phone, and even credit cards become pretty much
> useless. Remember
> how often you are asked for "your name, as it appears on the
> credit card".
> So, why not encrypt the card number and name before storing in your
> database. A simple little home grown program to use RSA or other
> encryption, and very strict controls, RACF or other, as to
> who/what can
> access it. Your data is safe from both inside, outside, and
> just plain
> mistake compromises.
> Hey, I love neat new hardware and software as much as
> anyone, but
> it looks like a complete waste of money and time for most
> businesses. Or
> am I missing something here? Please shoot holes in this if I am.
I can agree with you in general. The problem is how to implement the
"field level" encryption __easily__. Especially with non-database files.
With a database, such as DB2, you could use a UDF to do the
encryption/decryption (but how do you present the keys?). With a flat
file or VSAM, then the application itself must be modified to call the
encrypt/decrypt function. And, again, how do you present the keys?
(perhaps RACF could help with the RACDCERT somehow).
We had a programmer want to do this for a sensitive field. When he found
out that it could not be done automagically, he just gave up on the
idea. He was on a deadline and could not afford the extra time for
development.
Another thing is that encrypting on DISK means that every record
read/written requires one or more calls to the encryption subroutine(s).
This increase CPU utilization. We are already 100% CPU quite often. And
upgrading is simply out of the question due to the software fees
involved.
Keeping the data unencrypted on DISK just makes life "easier" for the
programmers. And, remember, that application development on the z/OS
system really "lags behind" that on the Windows or Linux systems. Or
does WD4z allow more "drag and drop" type programming? Even if it does,
where is the prewritten encryption software to be "dropped in"? Anyway,
anything that slows down development is "bad" because (1) users want
their application right this very second and (2) it costs more. Both
give the z/OS system a "black eye" that other people are willing to use
to decry its usefulness. And I, personally, have gotten weary trying to
educate the "aggressively ignorant" who simply have their own agenda and
don't want to hear the truth. In fact, one person who used to be here
was "too agressive" about the truth. That's why he isn't here any more
("not a team player"). Granted, that was two CIOs ago, but still...
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
