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.
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.
> and only connect the machine to any network
;) This also kinda relies on a security through obscurity standpoint, which contrary to popular belief can actually be useful as long as you don't let it lull you into complacency.
> (internal and external)
If you're unable to do this (due to staggered billing or something) the "next best" option is a heavily restricted network.
Give your machine with the personal information precisely one network connection and plug it into precisely one machine that can talk to the secured machine on precisely one port. Have your border firewall or equivalent drop any outgoing packets from either of these machines. Only let people do work on this machine from the console. Also use a straight cable between the machines.. ethernet port to ethernet port, crossover cable.
Then you have your webserver talk to the intermediate machine to handle transactions. Process submits authorization or billing request to intermediary, intermediary talks with the database, and issues a "yes" or "no" to the querying program. At some point you'll probably have to actually transmit user data to actually do the billing, so obviously everything in this chain will be encrypted.
Then install the best intrusion detection tools you can find/afford on all these machines and hire alert people to monitor logs. Treat any unexpected traffic as an attack and have someone walk over to your machines and physically unplug the machine from the intermediary until the situation can be identified/resolved.
This obviously assumes one believes that physical separation is important and effective, which I happen to do.
If server theft is a concern you'll also want to yank out floppy drives, physically secure the server somehow, look the bios, and if you absolutely require being able to copy data to this machine give it a read-only cdrom drive.
IMO, I wouldn't back up the server except for a hard drive image you can use to reinstall everything to a known state. Were I joe online shopper, I'd much rather re-enter cc info than worry that tapes were floating around the country with my data on it.
If you did even half of this, you'd have several times the level of safety than I've personally seen on some other online merchants, and I've been through a good number of data centers.
That is the worst idea I have ever heard. Suppose you decide to store the latter half of the card number in a cookie, and some other site decides to store the beginning part in a cookie, using your method, bam plaintext credit card number on the user's computer, which is probably the least secure place for it to be stored in plaintext, since they probably have an open read-write SMB share hanging out from the latest MS worm.
This goes to show why it is very dangerous to "Ask Slashdot" about anything important or security related.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
First of all the biggest risk is from internal theft. This can be handled by keeping the box secure both physically and from the internal/external network. Secondly the processor must get the data in a usable form thus it must be transmitted over the Internet as open text unless the processor has an encryption they want you to use. I solve this problem by sending the information to my card processor over dial-up lines. Yes it is slow, (1200 baud) but I can process 800 credit cards in about 45 minutes. The problem that I see for you is not the storage of the card info but the transmission over the Internet. You mignt want to look at ICVerify. This is piece of software that has been around for a long time and works fairly well. You can also process in real-time if you need to for sign-ups.
SurePay is on the way out. They've made a deal with Verisign to migrate users to the Verisign Managed Payment Gateway. The SurePay gateway is only being maintained for existing customers. It should not be used for new development.