Just a couple weeks ago Microsoft announced that Azure is fully compliant with PCI DSS Level 1. This post is an overview of a few interesting security thoughts for Azure payment related development. First, PCI DSS stands for Payment Card Industry Data Security Standard. Azure is compliant with PCI DSS version 2.0 and was fully certified on December 31, 2013. Basically, if you plan to "store, process, and/or transmit cardholder data" you must comply with PCI DSS (reference). To be clear, there are actually 4 levels of compliance required of merchants and it is based on your annual transaction volume. The strictest is Level 1 for merchants with the most volume (millions of transactions annually) down to merchants with 10s of thousands (Level 4). Compliance should be taken seriously, because say for example Visa catches you intentionally storing cardholder data without PCI DSS compliance, you can be barred indefinitely from processing payments. Or, if you were required to be compliant at a lower level due to your lower volume (and thus risk surface), but you are breached; you may be required to be certified at a more strict higher level going forward.
Let's just list some of the base requirements imposed by PCI DSS
Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
5. Use and regularly update anti-virus software or programs
6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need to know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an Information Security Policy
12. Maintain a policy that addresses information security for all personnel
Although Azure is compliant with this list, there is still some responsibility on your part. Microsoft has identified key areas which are still your responsibility in the Windows Azure Customer PCI Guide.
A couple of interesting thoughts on this list relate to Items #11, #5, and #3:
Item #11 (Regularly test security systems and processes)
You are required to have a regular external vulnerability scan by an approved PCI DSS scanning vendor. Just make sure you let Microsoft know before you do that. Microsoft requires a 7 day notice for any type of penetration or simulated intrusion testing. Use this approval form and submit to Azure customer support. You may want to do this kind of penetration testing even if you don't process payment information.
Item #5 (Use and regularly update anti-virus software or programs)
This always struck me as a problem in the PAAS world. Assume for a minute you had PAAS VMs (web roles and worker roles), you would have had to use a startup script to bootstrap an antivirus setup each time you deployed your cloud service. You wouldn't be able to just RDP to that machine and install it by hand because if while you were away, your role instance blue screened repeatedly, the Azure Fabric Controller would just move your deployment to a new instance which would not have antivirus running and then you'd suddenly be non-compliant until you RPD and manually install again. Microsoft was certified compliant for compute, so I would expect to find that antivirus is now running as a process on your cloud service VM, especially since the Windows Azure Customer PCI Guide has it listed as a Microsoft responsibility. As a side note, another interesting observation is just how hardened a native Azure PAAS VM is. Consider for a moment that it is a stripped down, purpose-based, custom compiled version of Windows Server with all non-essential items actually removed from the OS. Although it shares the same SKU it is really not the same bits. A virus authored to move around and thru a typical OS host may not fare well with the amount of changes made to support what is essentially a bare metal IIS or WCF service host.
Item #3 (Protect stored cardholder data)
This is where it gets interesting. Maybe you want to process credit cards, but want to drastically simplify your compliance. This can be done by allowing a 3rd party who is PCI DSS compliant host your payment pages while you just show them to users in an IFrame. In this case, you have no liability. The only time you can get burned here is when you start touching the data again; say you want to store the card expiration date so you can send your customers reminders when their card is going to expire. If you ask your 3rd party for this information over a secure channel you can't store the information for fear of PCI DSS, but you could compute a random date from it and use it as a reminder date.
A 3rd pary I've used is Authorize.Net. They have several solutions, but one I like is called (CIM) or Customer Information Manager. Essentially in the industry it is referred to as a payment tokenizer because you never know the actual payment information of your users, just ids or tokens which represent forms of payment. By only storing ids for the user's credit cards you are not storing any sensitive PCI DSS information. You basically call a web service saying I need to create payment information for customer X and the web service returns a temporary token. You put this token in your html then launch an IFrame to present the payment form. After the user has added their payment information, you can find out an Authorize.net issued id which represents that payment information. When you want to bill this customer, you just call a web service with the correct payment information id and that you want it to be charged $50. You might be saying well what if someone hacked your database and stole the payment information ids? Well, when you call the web service to charge your users, you must also pass your subscription information. Authorize.net knows which payment ids are were issued to which subscription, and will only allow monies to be transferred to your subscription from valid payment information ids. So basically a hacker would not be able to get the money, but they could load your account with bad transactions from your own customers. This is not a huge incentive for hackers.
As you can see there is still a lot to think about when it comes to payment processing in any website. Thankfully now Azure is certified PCI DSS Level 1 for those with deep compliance needs. It is always best to not "store, process, and/or transmit cardholder data" (reference) if you don't have to, and a tokenizer can help with that.