Phil Smith wrote:
... and when decommissioning hardware-no more How many DSEs should
we do? or Should we take the drives out back, shoot ‘em with a
12-gauge, and then drop ‘em in the ocean?.
Actually, there is a much more interesting corollary to this scenario. If you
have a drive that
Microwave it!
/Steve
From: Todd Arnold arno...@us.ibm.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 2015-05-19 14:25
Subject:Re: PCI DSS compliance for z/OS
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Phil Smith wrote:
... and when decommissioning
Tom Brennan wrote:
As a side note, I bought a couple Western Digital Passport drives that
connect via USB to my PC (for mailing data). I copied data to the drive
and oops, I forgot to encrypt before mailing. So I ran through the
encryption process which suprised me because it only took a
Charles Mills wrote:
I think much of the problem is with credit card numbers themselves. There are
only ~10**16 possible credit card numbers -- many fewer if you allow for the
fact that only certain combinations are valid. A credit card number is easier
to brute-force guess than its encryption
On Tue, 19 May 2015 07:25:41 -0500, Todd Arnold arno...@us.ibm.com wrote:
Phil Smith wrote:
... and when decommissioning hardware-no more How many DSEs should
we do? or Should we take the drives out back, shoot ‘em with a
12-gauge, and then drop ‘em in the ocean?.
Actually, there is a much
charl...@mcn.org (Charles Mills) writes:
I think much of the problem is with credit card numbers
themselves. There are only ~10**16 possible credit card numbers --
many fewer if you allow for the fact that only certain combinations
are valid. A credit card number is easier to brute-force guess
On 17 May 2015 at 14:39, Phil Smith p...@voltage.com wrote:
Format-preserving data protection methods achieve PCI DSS compliance while
enabling persistent,
data-centric security. “Format-preserving” means that the encrypted/tokenized
values look and feel
like plaintext: same length, same
I think much of the problem is with credit card numbers themselves. There are
only ~10**16 possible credit card numbers...
Actually, it's much worse than that. You can't encrypt all of the PAN for a
credit card. Typically, the first part (the BIN) is required in cleartext in
order to route
Tony Harminc wrote:
I've heard about this format-preserving encryption for a while, but
haven't had the justification for spending time to really understand
what goes on. But it seems to me on the face of it that any such
encryption must be substantially weaker than what we usually think of
as
Subject: Re: PCI DSS compliance for z/OS
Charles Mills wrote:
I think much of the problem is with credit card numbers themselves. There are
only ~10**16 possible credit card numbers -- many fewer if you allow for the
fact that only certain combinations are valid. A credit card number is easier
Russell Witt wrote:
Interesting discussion. But taken another step, wouldn't the same also apply
then to encrypted physical tape? As well as encrypted virtual tape? I believe
that all physical tape encryption is done in a fashion similar; if you have
authority to the data the volume will be
Todd Arnold wrote:
The article you referenced seems to assume whole-disk encryption is always
implemented using software on your computer, since it says the operating
system has the decryption key to access the disk. That is not true, of
course, for self-encrypting disk drives (or tape drives)
Phil Smith wrote:
... and when decommissioning hardware-no more How many DSEs should
we do? or Should we take the drives out back, shoot ‘em with a
12-gauge, and then drop ‘em in the ocean?.
Now you're spoiling all the fun! But that's a really good point I never
heard before.
As a side
The article you referenced seems to assume whole-disk encryption is always
implemented using software on your computer, since it says the operating
system has the decryption key to access the disk. That is not true, of
course, for self-encrypting disk drives (or tape drives) where the
On Sun, 17 May 2015 11:39:25 -0700, Phil Smith wrote:
Warning: long post ahead, and of course it’s pushing the hammer that we sell
My eyes tend to glaze over when these threads arise, but I did at least learn
that HP had acquired Voltage ;-)
Shane ...
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Phil Smith
Sent: Sunday, May 17, 2015 11:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PCI DSS compliance for z/OS
Warning: long post ahead, and of course it’s pushing the hammer that we sell,
but (I believe) there are universal
Smith
Sent: Sunday, May 17, 2015 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PCI DSS compliance for z/OS
Warning: long post ahead, and of course it’s pushing the hammer that we sell,
but (I believe) there are universal truths included.
Frank,
You’re asking the right questions. The basic
-- Forwarded message --
From: Frank Swarbrick
frank.swarbr...@outlook.commailto:frank.swarbr...@outlook.com
Date: Fri, May 15, 2015 at 1:35 PM
Subject: PCI DSS compliance for z/OS
To: IBM-MAIN@listserv.ua.edumailto:IBM-MAIN@listserv.ua.edu
There has been a lot of discussion back
: PCI DSS compliance for z/OS
There has been a lot of discussion back and forth at my company as to what it
means to meet the PCI DSS (Payment Card Industry Data Security Standard)
requirement for data at rest, which I believe refers to the following from the
PCI DSS v3.0:
3.4 Render PAN
There has been a lot of discussion back and forth at my company as to what it
means to meet the PCI DSS (Payment Card Industry Data Security Standard)
requirement for data at rest, which I believe refers to the following from the
PCI DSS v3.0:
3.4 Render PAN unreadable anywhere it is stored
20 matches
Mail list logo
