January 19, 2011 at 9:33 am
I have 2 DBs one of them is ina highly secured offsite environment it has 2008 Ent
second one is 2005 in my own network.
I get these huge file with CC Nums and associated content.
There are nearly hundred processes that make use of this data keeping the CC num as ref number or A/c number.
Since my enviornment is not compliant to keep those Cc nums (and i cant make it compliant) i wanted to make use of teh highly secured offsite network with SS 2008 ENt on it.
I need suggestions for the strategy..
My thoughts:
Imort the Data from client directly into the secure environment
Substitute teh first 10 Digits (out of the 16) with a autogenerated SEQ number.
Create a look up table where we have atleast three columns,
OrinalCCNUM(16), 10DigitCode(10), NewFakeCCNUM(16)
Now replace the OriginalCCNUM with FakeCCNUM.
Now we have all the card associated content with a fakenum (since CCNUM i used just as a reference fake is OK)
Send out the File to SS2005 environment to be processed , after it goes through the all the processes, Import the file back to SS2008 environment, Replace Fakenum with Original and send the results back to client.
Do you think this works ?
Any ideas or new thoughts to approch this problem are most welcome.
[font="Verdana"]
Today is the tomorrow you worried about yesterday:-)[/font]
January 19, 2011 at 12:43 pm
Your approach appears to be good. Although when I think of the hassles of the substitution process then the minute intricacies start appearing. My very first questions are
1) What is the frequency of the import/export of data to/from the 2008?
2) During each import of the files, are the CC #'s going to be different? You dont want to assign 2 separate fake CC #'s to the same account 😀
3) The size of the data??
4) Any chance for you to replicate the data onto your 2005 environment?
I could think of more if you could provide a little more on what exactly are you trying to achieve.
January 19, 2011 at 2:35 pm
Intiguing Quetion Mr Rijiv
1) What is the frequency of the import/export of data to/from the 2008?
Frequency is roughly weekly.
2) During each import of the files, are the CC #'s going to be different? You dont want to assign 2 separate fake CC #'s to the same account
I like this question, had to clarifiy the same with my business team, NO(thank God :-)), every time we get new CC#'s.
3) The size of the data??
There is no estimate but would not be more than 500 MB woth of DATA
imagine a CSV with 75,000 Rows and with say 20- 30 columns ..
4) Any chance for you to replicate the data onto your 2005 environment?
I dont think so, i was thinking like a SSIS export(2008 to my N/W) and Import(My N/W to 2005).
What am i trying to achieve ..
Replace all CC# nums from enviorments with a fake CC# by replacing first 10 (flexible) with a generated SEQ num.
End of the day some process needs to know what is the original CC#
At that time, go match the fakecc# with originalC## using teh LUKUP tabel located in 2008 Secure environment, and pull back the Original CC#.
Ex:
We decided to send neww offer adv letters to all customers who have Good Credit Score , we look it up in the tables and all the corresponding addresses are pulled, now we need to put their CC# on their letter, but we have a fakecc# so , Every time we need to do soemthing like this , a list of fakecc#'s comes to me , i wil run it against ss2008 that get back to me with original CC#s.
Hope this made sense, feel free to throw more questions.
[font="Verdana"]
Today is the tomorrow you worried about yesterday:-)[/font]
January 19, 2011 at 2:52 pm
Now I see what you are trying to achieve. So here's the scenario (from what I understood)
Once you get the CSV, you are going to replace the column (CC# Original) with a fake CC#.
At this point, you will need to store the Original CC# and the corresponding Fake CC# on a separate table/CSV/some other means to make sure that when you try to map it back, you don't have any mismatched CC#'s.
Once you have done this, you export it to your 2005 site from where you do whatever you want.
Once done, you send it back to your secure site and replace the fake CC#'s with the original ones.
My only concern would be mapping back the CC's back and forth. If the logic for replacing and mapping malfunctions, its gonna be one real trouble. So I am guessing that you might have already thought about it. That being said, I think your approach is good and can be implemented with some more careful thought and planning.
January 19, 2011 at 2:59 pm
thanks Again.
Most of this is on paper still. But planning to implement soon.
Ideas on the " Mapping Loggic " would help too.
I decided with first 10 digits , coz dat way we have last 6 to run a comparison against.
And I was thinking like to keep the LookUp Table exclusive for each Batch of client file..
Just in case if some thing happens , wouldnt that help looking up ?
[font="Verdana"]
Today is the tomorrow you worried about yesterday:-)[/font]
January 19, 2011 at 4:30 pm
allin1 (1/19/2011)
thanks Again.Most of this is on paper still. But planning to implement soon.
Ideas on the " Mapping Loggic " would help too.
I decided with first 10 digits , coz dat way we have last 6 to run a comparison against.
And I was thinking like to keep the LookUp Table exclusive for each Batch of client file..
Just in case if some thing happens , wouldnt that help looking up ?
I'd vote against the approach of replacing just the first 10 digits. Based on the length of the CC number it seems to be possible to narrow down the most probable issuer in some cases(e.g. length of 15 = AMEX) allowing to replace the first few numbers with the known issuer code. There might be algorithms out there to break it down even further...
[Edit:
after a little more web research:
Example: AMEX card numbers start with xx, digits three and four are type and currency, digits five through 11 are the account number, digits 12 through 14 are the card number within the account and digit 15 is a check digit.
So I already know 4 out of your 10 numbers. There are also some rules that apply for an account number. And, (un)fortunately, you left the check digit in there. The algorithm is known....]
I strongly recommend to talk to some of the CC security authorities on how to handle such a scenario. Whatever you do outside the secured system: you need to make sure there is no way to link back to the original CCN. And I'm not sure if a partial replacement of the CCN will qualify, especially not the leading part....
I see two options to avoid the hassle:
1) get your 2K5 system qualified or
2) plan to transfer the logic into the secured 2K8 system.
[Edit 2: Disclaimer:
I'm not working in a CC related industry. The stuff I posted is the result of a 30min web search and a few additional tests. However, as a person using CC's I'd be concerned if someone would use my CC data in the way discussed in the other posts...]
January 19, 2011 at 6:22 pm
I agree with what LutzM is saying. But at the same time, if the process of changing the numbers is not visible to anyone, you should still be ok (ok because there is always a chance of someone breaking into your algorithm). So consider talking to someone in the CC industry to handle this interchange.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply