These are not the credit cards you're looking for

My presentation from the Scottish Ruby Conference about PCI DSS, what you as a web developer need to consider and some straight-forward and hopefully common-sense ideas based on my own experience in building the compliant infrastructure and software for a PCI DSS Level 1 service provider.

Transcript

1. These are not the Credit Cards you’re looking for A hopefully interesting PCI DSS introduction Ryan Stenhouse, Ruby Engineer @ryanstenhouse ryanstenhouse.eu
2. Hi, I’m Ryan Stenhouse ‣ @ryanstenhouse ‣ http://ryanstenhouse.eu ‣ Blogs, writes Ruby, has been through PCI DSS compliance as a Level 1 service provider ‣ Works with the awesome folks at FreeAgent Ruby Engineer at FreeAgent
3. PCI DSS - Guh, wha? How to baffle a room-full of people in one go ‣ PCI DSS is a mandatory security standard that everyone who deals with credit card information has to adhere to ‣ Complicated and annoying, but defeatable with common-sense and good planning ‣ Can’t be ignored ‣ Can be quite costly
4. ‣ Self-Assessment Compliance ‣ What you need to worry about ‣ Where it gets annoying ‣ Quick wins and bear traps ‣ Logging I’m going to talk about: How to baffle a room-full of people in one go
5. ‣ Probably the most relevant to the audience here. ‣ SAQ A ‣ SAQ C ‣ There are others Self Assessment Tax doesn’t have to be taxing
6. SAQ A - Nice and simple Nothing to see here sir, move it along ‣ If you outsource all your card processing to someone like PayPal and never touch card data, this is for you. ‣ Only 13 questions to answer, from Requirements 9 and 12.
7. SAQ C - More involved ‣ If you capture, then transmit card information on (think ActiveMerchant) but don’t store CHD, then you need SAQ C. ‣ 80 questions to answer from requirements 1 - 9, 11 & 12. ‣ Needs a lot more documentation, business policy and technical work ‣ Probably ‘as bad as it gets’ More risk, but more reward
8. SAQ C - More involved ‣ If you capture, then transmit card information on (think ActiveMerchant) but don’t store CHD, then you need SAQ C. ‣ 80 questions to answer from requirements 1 - 9, 11 & 12. ‣ Needs a lot more documentation, business policy and technical work ‣ Probably ‘as bad as it gets’ More risk, but more reward
9. What to worry about ‣ For SAQ A, nothing. Really. ‣ For SAQ C, it gets more complicated. You need to have an organisation policy around development ‘best practices’ and security. You need to keep on top of patches, and you need to be up to speed on things like OWASP’s recommendations. ‣ I’ll come back to this later As a developer
10. What to worry about ‣ For SAQ A, nothing. Really. ‣ For SAQ C, you’re probably going to have to spend a lot of time hardening your machines, footering around with your network(s) and generally having a lot of overheads. There needs to be various documented policies covered that must be followed. ‣ I’ll come back to this later As a sysadmin
11. What to worry about ‣ If you’re not compliant, the consequences can be as dire as your acquirer stopping you from being able to accept payment by card and hitting you with massive fines. ‣ For SAQ C, you’re going to need to put in place a lot of policy and procedural documentation. ‣ You need to and must be PCI DSS As a business
12. Bored yet? Quick wins! ‣ Go for SAQ A unless there’s a good business reason not to. ‣ If you need SAQ C or higher, save some pain and kill your WIFI ‣ Outsource whatever you can to a PCI DSS certified supplier. Q: Did you hear about the constipated Accountant?
13. Here are the bear traps ‣ PCI’s logging requirements are challenging to say the least. ‣ For very small teams, you can’t always segregate roles and responsibilities as you’d like. ‣ Quarterly ASV scans, Pen Tests every time you make a network change. A: She worked it out with a pencil
14. Change Management ‣ You will need to have a documented and enforced change management procedure for your application(s). ‣ It needs to include the details of the change, why it’s needed, the impact of the risk, post and pre deployment test plans and a rollback strategy. Change is difficult and needs to be documented
15. FIM and IDS ‣ You need to be able to proceed your machines from unauthorised access and changes, a good FIM and IDF tool is required for this (if your firewall doesn’t do it). ‣ OSSEC, a free project by Trend Mirco is perfect for this. On your cardholder environment
16. Logging ‣ PCI’s logging requirements are vast, complicated and crucial to maintain a useful audit trail. ‣ Logs should be centralised, backed up and properly protected against unauthorised changes and access. Harder than chinese algebra
17. Logging ‣ You need to keep 6 months on hand and 2 (or more) years worth in archive. ‣ Logs need to be audited. ‣ The creation of logs needs to be logged. ‣ rsyslogd and a lot of painful configuration is good enough if you document what you do Harder than chinese algebra
18. About networking ‣ You need to properly isolate your cardholder environment from the rest of your network. ‣ This will mean one of more firewalls, iptables has been good enough for me in the past. ‣ You need to regularly audit your firewall configuration (quarterly). ‣ Penetration tests every time you Ask me more about this, I tend to ramble
19. Misc Advice ‣ VM’s are a-ok as far as ‘servers’ for PCI are concerned. ‣ You need identify and isolate ALL of your cardholder data. Consolidate it to one place and your life will be easier. ‣ If you’re in doubt, hire a QSA for the day (Might be quite expensive). Stuff that occurred to me as I was writing this up