Slide 1

Slide 1 text

These are not the Credit Cards you’re looking for A hopefully interesting PCI DSS introduction Ryan Stenhouse, Ruby Engineer @ryanstenhouse ryanstenhouse.eu

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

‣ 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

Slide 5

Slide 5 text

‣ Probably the most relevant to the audience here. ‣ SAQ A ‣ SAQ C ‣ There are others Self Assessment Tax doesn’t have to be taxing

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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?

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

No content