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.

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

2. Hi, I’m Ryan Stenhouse
Ruby Engineer at FreeAgent
‣ @ryanstenhouse
‣ http://ryan.stenhou.se
‣ Blogs, writes Ruby, has been through
PCI DSS compliance as a Level 1
service provider
‣ Works with the awesome folks 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. What I’m going to talk
about a room-full of people in one go
How to baffle
‣ Self-Assessment Compliance
‣ What you need to worry about
‣ Where it gets annoying
‣ Quick wins and bear traps
‣ Logging

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

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
More risk, but more reward
‣ 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’

8. SAQ C - More involved
More risk, but more reward
‣ 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’

9. What you need to worry
about
As a developer
‣ 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

10. What you need to worry
about
As a sysadmin
‣ 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

11. What you need to worry
about
As a business
‣ 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

12. Bored yet? Quick wins!
Q: Did you hear about the constipated
Accountant?
‣ 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 ceritfied supplier.

13. Here are the bear traps
A: She worked it out with a pencil
‣ 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.

14. Change Management
Change is difficult and needs to be
documented
‣ 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.

15. FIM and IDS
On your cardholder environment
‣ 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.

16. Logging
Harder than chinese algebra
‣ 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.

17. Logging
Harder than chinese algebra
‣ 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

18. Some stuff about
networking I tend to ramble
Ask me more about this,
‣ 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

19. Misc Advice
Stuff that occurred to me as I was writing this
up
‣ 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).