Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Credit Card Encryption & System Copy

Former Member
0 Kudos

Hi All,

We have done a system copy from PRD back to QA (credit card encryption is activated on both servers). The customer would like to be able to read the PRD data including the credit card details but of course the QA system can only de-crypt its own data and not the PRD data. Is there a way of de-crypting the PRD data that is already within QA and then re-encrypt using QA key?

I didn't set up the original encryption so I am learning about this as I go.

Thanks.

11 REPLIES 11

Former Member
0 Kudos

I don't think that what you're doing here is in any way conforming to the regulations of PCI DSS. What you want to do is dangerous and can have very grave consequences. I would strongly advise you to destroy the credit card data in QA!

Assuming you used the system PSE for encrypting the data: You'll have to export this PSE from PRD using STRUST and then, also using transaction STRUST, import into QA.

0 Kudos

Hi Sietze,

Well, I have advised this to my customer, but at the end of the day the customer owns the system and he wants to be able to see the Productive data in the QA system.

I will have a go at importing the PSE. But I also do not want to overwrite the QA one. Will see how I go. Thanks

0 Kudos

Another possibility is to "scramble" the data, thereby making it "anonymous" but still usefull for testing.

Cheers,

Julius

0 Kudos

You can save the old PSE first if you want. Either use STRUST or the filesystem.

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

>

> Well, I have advised this to my customer, but at the end of the day the customer owns the system and he wants to be able to see the Productive data in the QA system.

Well, the upper management of this customer is finally (legally) responsible to ensure that access to this sensitive data is controlled and restricted (no matter where it is stored - if the data is replicated then all storages need to be protected with the same strong mechanisms).

Usually access to non-productive systems is much easier (less restrictive). So, the customer is taking quite a huge risk that this sensitive data might be less protected than (legally) required.

Aside of legal consequences the loss of trust / reputation might impose an even higher (business) risk. I would consider twice ... (but I'm not the CEO nor the CIO of that customer) ...

PS: for your own protection I'd strongly recommend that you inform the customer on those risks (in written form) and let him sign-off that you've warned him ... (otherwise you might be kept liable as well - if being engaged as adviser / consultant).

0 Kudos

In an ideal world, the QA system should have the same status as PROD (config, roles, programs, connections, etc) to be able to test properly...

But of course there is testing going on and application support and (anonymous) test users can be expected to have the business access as well.

I spent the whole day today with "Datenschutzbeauftragte" from DSAG (data protection officers of the German SAP User Groups) and I don't think that they would approve such a copy of such data into such a system (if asked).

Cheers,

Julius

0 Kudos

Hi All,

Well you have given me some food for thought, thankyou for your comments.

I will go back to the customer and re-state the risks. After all I can't really see why they need to physically see the credit card data anyway - it's all there, just can't be read.

-Natalie

0 Kudos

I'd have to agree with Sietze here. Creating essentially a full copy of all the credit card account numbers stored in a PRD environment is opening yourself up to a greater risk of having card account numbers compromised.

This is actually a common request from our customers and we advise, as others have in this thread, that you replace all the card account numbers from PRD with "dummy" card numbers. It's fairly easy to write a little ABAP program that would, for example, change all Visa card account numbers to 4444333322221111 or all MasterCard numbers to 5555444455554442. That will still allow you to run reports that search by card number.

However, to stay PCI-DSS compliant you really shouldn't be trying to get a copy of card PRD acount numbers in QA.

0 Kudos

Hi Eric,

Thanks for your comment. The problem is not so much the credit card value, what we are finding is that in transaction XD03 when we load a customer who has one credit card that was created in QA after the system copy (so the entry shows up fine), and one credit card that was created and brought over from PRD. Not only does the credit card info not show up (the one from PRD), but the entire record is absent when you click on 'Payment Cards' for that customer. You only see the first entry (from QA). However if you go to SE16 and display table VCKUN and load that customer, you can see both entries. What I thought should be happening in XD03 is that both records would be displayed, but the CC info for the PRD entry would be masked, garbled or even blank (which would be fine). I suppose we are puzzled as to why the entire record gets omitted.

- Natalie

0 Kudos

How about when you look in SE16 at the other Customer Master credit card related table, VCNUM? Can you find a corresponding entry in that table that matches the card number stored in VCKUN-CCNUM? If not that would be the problem.

It's very likely that the encryption/decryption is preventing a match between the records in VCNUM & VCKUN. I'd be curious though what SE16 shows for the card number that you find in the VCKUN-CCNUM records.

Eric Bushman

<removed_by_moderator>

Edited by: Julius Bussche on Sep 30, 2008 9:52 AM

Please use your SDN Business Card only. We do not want the problems from the past with links and mails and telephone numbers all over the place

0 Kudos

Hi Eric,

Yes in VCNUM I also have the two corresponding records. One thing I do notice is that the credit card that does not appear in XD03 (ie: the PRD one) is actually expired in terms of validity. Please excuse my ignorance on this one as I am a basis consultant and not functional or FI, so I am not entirely sure how the transaction is meant to work. Wonder if this is the reason it does not get displayed? In which case I will ask the customer for another example.

- Natalie