Slashdot Mirror
Responsible Handling of Billing Information?
moving on asks: "I've
been asked by a client to build a fee based subscription service using
surepay as the vendor for processing credit
card transactions. Subscribers to the service will be billed X amount per month and
that is the rub. Surepay does not offer recurring billing so I will need to
store credit card numbers and related info. The question is then, how does one
best do this in the most responsible manner?" The trick here is giving
consumers the service they have come to expect from most websites,
without exposing their personal information to would-be thieves. Do you
think such a system is possible?
Why not use a billing service that supports the subscription model you want, rather than trying to find some minefield-laden path toward storing credit card info?
When I was a kid, we only had one Darth.
Store half the credit card number and half the expiration date in a cookie on the user's computer. Store the other half in the database, encrypted.
Even if someone cracks the server, the database itself will not yield valid CC's.
If the question is how to store data in a responsible way, why not ask Surepay, who you are sharing the sensitive data with? Surely they will have some insight into this, and because you are a client, may be more apt to share it.
Maybe your question could be asked how to safely transfer it?
-- Dan
I've thought about this problem a bit, but never really had to implement anything, so anything I am about to say, should perhaps be taken with a grain of salt.
One assumes that the web server is insecure, and therefore is going to store the data on another "secure" machine.
One needs to make a very specific interface that one can use for the "insecure" machine to talk to the "secure" storage machine (this is the machine that is going to do the cc verification also)
Presumably, the "secure" machine is not going to be running any services that are accesible to remote users besides whats needed for the the web server to talk to it. One can do something like only allow the machine to talk to the "insecure" webserver, but this doesn't buy you much more security, as all someone has to do is crack the "insecure" web server and you are at the same place you were before.
Getting back to the interface these programs speak. One basically needs an "input" func, and a "status" func.
Basically when one register with the site, the werb server doesn't store any information about the credit card on itself, as it immeadily connects to the "secure" machine and uses the input function to inform it about the new account.
It can then use the status function to determine that status of that account
status can be OK, or NOT_CHECKED_YET, or NOT ACCEPTED or the like. but basically something that is read only by the server.
Both of these services should be easy for the "secure" machine to check that its getting properly formed requests (i.e. is someone is trying to attack it). One can also make a script that then verifies each account each month, and since one can do this over a phoneline, you don't even need to allow any other outbound connection from this machine.
yes, a little bit more thought probably has to go into this, but this is what I came up with a while ago. feel free to criticize away.
Though there is no really good way to do it, the safest way to do it is to isolate credit card info onto a seperate box, limit the access to that box to the absolute minimum required to request a charge, and have that box then directly contact the credit card clearinghouse rather than return a CC# for use by the other half of your application.
Encryption (SSL minimum, preferably also encrypted in store with keys being supplied by the other half of the application) is necessary, the lockbox code needs to be as limited in capability as can be, and what remains must be thoroughly audited to limit the likelihood of breach. No other services should run on that box, and physical access must be tight. A shared cage at Exodus doesn't do it.
Whatever you do technically, I think the most important thing is... don't forget to let the customer decide. Any app that stores CC info should allow the customer to decide NOT to have their info stored. I rarely see sites that allow me to "opt out" of having them store my credit card info, and I'd rather retype it than trust them.
Absolutely key to securing financial data (or really any data) is the use of good internal controls.
Most technologists spend a lot of time securing their data from external attack (i.e. a cracker). This is important but it is not the most likely threat.
Well over half of all thefts of financial data are committed by employees/trusted users of the company. Sometimes by the people who maintain the system and sometimes by others.
You combat this two ways. First with technology, the system (in this case probably a database) that contains the data should be access controled. It is also a good idea (and required by visa/MC) to encrypt the data. Another thing to watch out for is that you are not putting the credit card data into any other places, i.e. log files. you need to physically control access to the hardware running the system. Finally watch out for your backup tapes/media, especially if they are stored offsite.
On the soft side you want to have good audit controls on the data. Whatever method is used to access the data should leave a record of it doing so in a manner that is hard to compromise. People who don't need access to that data should not be allowed near it. Finally you need to be able to trust the people with access to the sensitive data, depending on the level of sensitivity this could involve cursory or invasive background checks. Banks background check their employees rather carefully, and for a reason.
Some things you can "sup-up", but certain features don't come on the Yugos of the world...Good luck on reprogramming the manager instead
---"What did I say that sounded like 'Tell me about your day?'"---
This doesn't solve the problem, it just transfers it to somebody else i.e. the credit card processor. Now you as a user of the processor still have an obligation to your customers to assertain that the processor has proper safeguards in place.
There's also something to be said for keeping this data distributed. One humonguos database is a tempting target, and cracking one protection scheme nets a large return. Many small databases each with a different implementation would require a much larger expenditure of effort for the same return and might raise an alarm if other(s) got cracked first.
"Glory is fleeting, but obscurity is forever." --Napoleon Bonaparte
As you consider ways in which to provide safe escrow for the customer's personal information, you might consider consulting your corporate attorney to get an appropriate waiver of liability in place. By storing the credit information beyond the life of the immediate transaction with your payment service, you're opening yourself up to additional exposure to yourself that I'd imagine isn't covered by the contract with the credit card processor. It looks like you're stuck in the realm of symmetric encryption techniques for the information, and there are steps you can take to protect your encryption keys. But even with good physical and software security (hardcopy keys in bank vaults, regular key rotation) it would be prudent to limit your liability. Something else to to check into is any additional privacy regulations that may apply if you end up being a financial "intermediary". One of particular note is Graham-Leach-Bliley which requires certain disclosures when you have certain roles in financial transactions. Again, a real legal opinion is probably your best bet here.
Physical security is a good road to go down, but it would be just as easy (if not easier) and cheaper to shove the data onto an encrypted file system, and then only mount the file system twice a month (1st & 15th billing cycle(s). The problem with "disconnected media" is that you have to save a queue of client requests. I'll get more into that in a second. I don't have a great solution on a shoestring budget, but I can point out some things to look for... /. reader saw a story last week about a huge security flaw in the new 9i product (I was personally very saddened by this). You're not going to get rock solid security from Microsoft or from the Open Source applications out there (again I'm talking out of the box). Protecting your customer's data can be a full time job. To truly protect your boxes and your data, you have to be aware of new vulnerabilities. You will need to live a security websites; you will have to dedicate yourself to not installing any new commercial (non-home grown) applications on these boxes without putting them to the test on another system first, and you will have to monitor the activity to that machine with a fine tooth comb every day even when it would seem that nothing bad is ever going to happen to the system. I've seen the best of security measures crumble because tech's to did security gat a false sense of security because they where used to not being attacked.
First define your goals from the customer side. Do you want to allow your customers to decide what day of the month their CC will be billed? Do you want the customer to be able to change their CC#? Do you want the customer to be able to pay for 2/3/6/9/12 months in advance? Do you want to allow you customer to select an option to only 'bill once'? The goal of your application will determine how you store you sensitive data. Someone who wants a 12-month subscription and would like to use the 'bill once' option tends to be okay with updating his/her records every billing cycle. While the month to month guy doesn't want tge hassle from a reputable company.
Also consider (in the case of removable media) that if a customer wants to cancel their account, you as a company want to get rid of their data like a hot potato. If you have to wait for the next tape to be inserted to remove that account, you are still liable for their data. And that is an expense that no company wants or needs. Client request queue's are cumbersome to manage, usually rely on unstable environments, and are certainly not ideal for security. If you had to wait on a tape to mount to add a new account, where are you going to store that account's information until the tape gets inserted? I would think that in any case no matter what the requirements are, a removable media solution is out of the question.
While I'm on the subject, let me point out that nobody is going to do this for you out of the box. The commercial says that 95% of top 60 E-businesses run Oracle, and yet every regular
"We haven't been attacked, so we probably never will be.", "they don't know we are here.", and "My machine isn't really connected to the internet." may be statements that is true enough, but that doeesn't allow you to rest on your laurels. Security though Obscurity doesn't work. Trust me, if they want to, they can come though your firewall (usually a Trojan), around/into your NAT tables, and into that box that isn't really on the internet. I don't know of a security tool that can't be fooled (except a person that can make on the fly decisions).
So we come back to 'out of the box security tools'. The correct way to modify them is with education about them. The more you get to know about your firewall(s), and your router(s), or your web server(s), and your [insert long list of hardware/software widgets here], the easier it will be to understand how to protect yourself. It wouldn't hurt to pay for a class on how to make modifications, as this would give you the voice of someone with a broad experience in dealing with your tools.
So, My answer to your question, as long and rambling as it may be, is pretty simple. Stay away from Microsoft OS's as their security holes are much more publicized to the general public than that of the UNIX/Linux world. Use a peer system with ALLOW/DENY rules setup in your boxes. Have your content server(s) connected to a broker server that can then connect to your database. Never access your data on the database from any other machine (no remote ODBC, TNS, etc...). Have the database do it's own lookups and queries. Then use some form of encrypted communications to relay information from the database to the broker. The broker should make an intelligent decision as how and where that data gets sent. If you connect to the clearinghouse via TCP/IP, then have the Broker hand off the data, and not the content server. As far as a customer is concerned all of this is transparent. To the cracker there are layers of walls to break in order to get to the data.
I would love to promote the software that you should run on the Broker machine, but contractually I cannot. Remember as you look for, or develop your broker machine that THAT machine is your security backbone, and should be treated if it was your daughter. I hope this helps, and I wish you the best of luck with your endeavor
There's no magic bullet for this - you can't say use GNUfoo or Sun iMumble, it'll do all you want and wipe you bum too.
The only one liner I can give you is Security In Depth. Use lots of layers of security and at every layer assume that the one above has been fully compromised. Your DMZ should be well firewalled, permit only ports 80 and 443 (HTTP and HTTPS), deny and log anything else. Your DMZ servers should assume that they can be attacked on any port from any host what so ever. Use the most minimal OS install you can and pick an OS that can be secured and will let you do a minimal install. RedHat has too many features for my taste - you don't want a friendly machine, you want a very unfriendly machine. I would suggest Slackware or Solaris from the general purpose OS pool, or Bastille Linux or OpenBSD from the secured OS pool. Disable or remove inetd completely - it tries to be friendly. Permit no unencrypted traffic. Use tripwire, and be able to reimage the mahines rapidly.
Your inner firewall should be of a different make to the outer one and should assume that all hosts in the DMZ are compromised. Permit only connections from specific hosts on specific ports to specific hosts on specific ports. Anything else should be denied, logged and the warning sirens sounded.
Behind here would be your working net where (relativly) non-secure business functions live. Once again, these hosts should assume the worst and that they have to fend for themselves. Etc. Use your imagination.
One last firewall, preferably a different make again, similar to the last, specific hosts and ports only. You may want to be more cautious about sounding the claxons however, windows likes to chat to things and users occasionally do silly but harmless things - this is not to say drop your guard, just that sleep is sometimes useful.
Next is the secure net. Absolute bare bones here. What this consists of depends on your application, but usually business logic, database and credit card processing live here, each on their own box, set to maximum paranoia security. Log everything, every login, every logout every process run, every request made, when and by whom. You'll need lots of disk space, archive regularly to read-only media, make several copies and store them in multiple secure locations.
IDS - Intrusion Detection Systems. These're useful, use lots - different types, different makes, even write a few of your own.
Incident response. What to do when your firewall is breached. What to do when your web servers are breached. What to do when your working net is breached. What to do when it is an inside job. What to do when your data is stolen. This is where your IDS comes in handy, if your data does walk, you must know where, when, how and who. Access procedures are useful. You will probably never be able to ensure that no one employee can steal your data, but you can ensure that no one employee can steal your data and cover their tracks.
Note that the word "if" was missing from the last paragraph. If lets you cross your fingers and hope it wont happen. Plan for when, not if.
Software. Encryption is good. Make sure and pick the right encryption for the job. Credit card data needs to be decrypted, I would suggest BlowFish, passwords don't - try MD5. Always practice safe key management remember your data is only as safe as your keys. Having said that, if your database encryption is ever tested for real you are this > < far away from a Worst Case Scenario.
Literature. There's lots of literature about, read some of it. Learn to break into computers, try to break into yours. Read some of the OpenBSD stuff, read Bugtraq and the other stuff at SecurityFocus, even if it isn't directly related, the attackers can think laterally, you must too. Try farther afield - failsafe engineering disciplines are a good start (try a google on SAFF for places it really matters.)
I posted a brief overview of a solution using PGP eariler. It was by no means perfect, just intended to point you in the right direction.
Then I began to read what others had posted....
The best advice I can give you is not to trust anything you read here. Some of the solutions suggested are just bad. I am a security professional so I have some experience in this area. As others have said, recognize that you are not equiped to handle this. Find someone who is.
But before you outsource, hire consultants, etc... remember -- technology is only a tool. I've seen technology based solutions that were more vulnerable than the problem.
You have a specific set of risks. Choose a solution that helps to mitigate those risks. Remember to document. Remember people actually have to use the system. Remember a create a well-defined process. Remember to create and enforce policy.
Also, look to the three R's. I could not find a single post that specifically mentioned recognition.
Resistance: how can I protect the integrity and privacy of the card numbers?
Recognition: how do you know if a breech of security has occured?
Recovery: how do we recover from said breech?