I'm currently creating an application for a customer that will allow them to automatically bill their customers credit cards.
I'm curious as to what are some best practices to safely store and access the credit card information, and for that matter, any other sensitive information, like social security numbers, account numbers and so on.
I'm assuming encryption of some type will be employed, but before I dig in too deep I wanted to see how others are handling these types of requirements.
Not that it matters, but we are designing the software using Microsoft SQL Server for the database, and using C# and ASP.NET.
-
Read the PCI requirements. Everything will be there.
Actually, you must follow them.
mattruma : Can you elaborate some more ... maybe provide some links?mannu : Of course. :) The credit card companies united in an effort against fraud. Now, everyone who handles credit cards needs to follow these requirements. You can read a little about it here: http://biztechmagazine.com/article.asp?item_id=354James Schek : http://www.pcistandard.com/requirements.html -
Don't - I mean, do you really need to?
mattruma : I wish it was that easy ... but we have to.Simon Gibbs : There is a strong market of third party payment services who can receive the details for you and simply send a you a message when payment has been made. There are alternates like PayPal and you can protect the data with MD5 or SHA1 - discarding trivia such as the exact string of digits. -
1 - don't even collect SSNs unless you really need them. And unless you're a bank or the government, chances are you don't.
2 - don't collect other sensitive info unless you really need to
3 - use whatever controls are appropriate (separate machine for the database, firewalled, access controlled, etc) for the stuff youdo really need to keep.
-
Different PCI standards compliance is required for different applications. If your application simply collects CC numbers and then submits them to a 3rd party PCI compliant payment gateway, your compliance requirements aren't too bad - provided you don't store the card number or CVV.
In terms of logging, you should "gut" the credit card number, e.g. retain the first 6 digits and last 3 digits but obscure the intermediate digits. Do not log CVV at all.
The PCI standard documents go into great detail, but it all depends on the requirements of your application as to what level of compliance you require.
-
Use aggressive standards to secure the host system both in terms of OS and physical security, such as the NSA guidelines.
Put the database on a separate system from the web server or other functions to prevent physical access and permission escalation exploits.
Program defensively to avoid SQL injection attacks and similar exploits.
When developing, program with security in mind first. Coming back afterwards and applying security will be difficult and error prone.
Try to separate the various parts of the application... i.e. don't use the same viewer or controller for "public" access and "private" access.
Be aware of and comply with all local laws regarding handling of this data... There are a lot of them out there.
Keep a supply of envelopes around to notify your customers in the event of a breach. If you lose information for 26 million customers, you might not be able to acquire enough envelopes to meet the legal timeframe for notifying them of a breach.
-
Be intimate with the OWASP threats and know precisely how to counter them in your application and framework. It's hard to believe how many people embrace goofy half-solutions to SQL Injection and cross-site Scripting attacks.
