Credit Card Security
for the SQL DBA
Andy Warren
I’m Andy Warren
• I’ve worked with SQL Server since 1998
• I’m a consultant in Orlando - sometimes I’m a DBA,
sometimes a manager
• I’ve served as the President of the Orlando SQL Server Users
Group, served on the Board of PASS, was a founding partner
in SQLServerCentral and helped launch SQLSaturday
• I spent two years immersed in PCI at an enterprise level – it
was incredibly interesting
Agenda
• Introduction to overall PCI concepts and how the audit works
• Review areas of PCI of particular interest to a SQL DBA
• Q&A as we go
Disclaimer
• I’m not a certified auditor or an attorney
• Rely on your compliance team
• Impossible to cover all of PCI in an hour (I’ll repeat this a few
times – attaining compliance doesn’t guarantee you’re
secure
What is PCI
• PCI Security Standards Council
• American Express, Discover, JCB, Mastercard, Visa
• Founded in 2006 with a goal of increasing awareness about
card data security to reduce losses due to fraud
• Annual filing required for vendors processing credit card
• PCI doesn’t cover banking information or PII – just card data
• PCI Standards evolve – the current standard is v2, expecting
a revision this year
• PCI is not prescriptive. Tells you what you have to do, not
how to do it – this can be frustrating!
• PCI is a lot about process and documentation of process
(maturity)
The 12 Core Requirements of PCI
Sub-Requirement Example
PCI Compliance Is Just the Beginning
of Security
• PCI doesn’t guarantee your data is secure, but it is a very
good start
• PCI only looks at ‘in scope’ systems. Don’t make the mistake
of failing to secure ‘out of scope’ systems!
• Consider PCI the absolute minimum you should do – its ok to
do more
Don’t Process Them
The best way to stay secure is to let someone else process them
in a way that the cards never transit your network (or at least a
network used for anything except card transactions)
Store/Transmit/Process = Scope
• Setting scope is a huge deal, it’s a collaborative effort and worth
the effort, should be as small as possible – you may hear this
referred to as the CDE (cardholder data environment)
• Systems that Store, Transmit, Process credit card data – even if
encrypted
• Out of scope
• Doesn’t store/transmit/process
• OR…is tokenized – the silver bullet (more in a minute)
• Scope isn’t just card data, it’s all the systems and processes used to
secure it (network, firewalls, change management, etc, etc)
• Scope is ultimately set ‘up hill’ from the DBA, but the DBA is an
important part of explaining and confirming the scope at the
database level
What You Can/Cannot Store
• OK to store any or all of the following
• First 6/last 4 of the card number
• Expiration date
• Full card number if encrypted (try not to)
• Do NOT – ever – store these
•
•
•
•
Magnetic track data
CVV or CVV2 (even on call center recordings!)
Unencrypted card number
PIN
Not In SQL Server
If you must process credit cards you should try really hard to not
store them in SQL Server (or any database):
• The only way to do this is to tokenize – an auditor acceptable
one way hash with card numbers stored elsewhere
I didn’t convince you, so…
The most important thing is encryption is mandatory.
• AES-128 or higher
• TDE or column, either can work. Or both!
• Encryption is easy – key management is hard
• PCI requires annual key change
• Dual authorization/split control
• Must have policy and proof
Logging
• PCI requires 90 days online, 12 months available
• Required for forensics and alerting
• Typically a combination of many different types of logs
Instance Logging
• Log failed logins (on by default)
• Capture changes to:
• logins, users, permissions
• The logging mechanism
• Use Trace, SQLAudit, others
• Better if DBA doesn’t control
• Policy that describes implementation and review
Application Logging
• Somewhere you should have the ability to determine who saw
what card when (this could be database or app)
• App level permission changes, login failure
• Policy on implementation and alerting
FTP
Basically evil, don’t use it, even if the file is encrypted
Internal Networks
• PCI doesn’t require encryption
• Don’t skimp – encrypt, at least the database connection
• It’s very easy to capture traffic on a LAN
• Separate PCI machines from the rest
• Non-trivial, lots of subnets and lots of firewalls and lots of gray
areas
Build & Harden Servers
• Only install what is needed, turn off anything not being used
• Design a configuration that will pass the internal vulnerability
scan
• Turn off the browser service and don’t run on 1433
• PCI doesn’t require C2/Common Criteria
• Lock it down as much as you can while still being able to
operate
• Document and get approval for any exception to your own
standard (or work to get the standard amended)
• Clearly this slide doesn’t give you all the things you
might/should do!
Change Management
• Change management tracking is required by PCI
• Should have change tickets for any change to production
• DDL or permission changes
• Encryption key changes
• Patching/hardening
• Tag your tickets so you can easily retrieve/report on them
Accounts & Passwords
• No shared accounts!
• Annual change or better for service accounts
• Better if split entry
• Strong passwords and no-repeat policy
• SQL logins aren’t disallowed, but not great
Non-Production Systems
• Systems that are not treated as part of scope and are not
secured/monitored to the same standard as production (PCI)
systems
• Cannot contain real card data – replace with test card
numbers or other substitute
• Replacement has to happen before data lands on non-prod
system – cannot restore and then replace
Vulnerability Scans
• PCI requires an external (public facing) scan each quarter by
an external vendor – all items have to be resolved
• PCI requires a quarterly internal scan using approved scanning
tool
• PCI also mandates at least an annual penetration test – active
attempts to compromise rather than just scanning
• Keeping up with vulnerabilities found by the scanner can be a
challenge, especially if you’re just starting the process
• Good build/patching process will eventually bring it under control
• Not all vulnerabilities are correct – they are ‘false positives’ and
you have to prove your case to get them removed from the report
• You may have items that you cannot fix, such as a system where
the vendor has gone out of business – in these cases you may be
able to have the CIO sign an ‘accept risk’ statement
Going Through the Audit as a DBA
• Review notes and findings from the previous audit – fix anything
that remained open and start to get your head in the game
• Answer the questions truthfully and be helpful, but much like being
in court don’t volunteer information that isn’t asked for.
• Capture screen shots as you go – I like to put them in a Word doc
with a note or two about them. Screen shots should be redacted if
they show card data or passwords before they are emailed – and use
care with the originals!
• Have someone with you to take additional notes for things you want
to look at internally
• Expect (demand) to have someone from compliance with you – they
can keep the auditor from pushing the boundaries too far and keep
you out of trouble
• You drive, the auditor shoulder surfs - should not give them
passwords or direct access. They may ask you to run scripts, ask for
time to review before doing so.
Resources
• Web Reading
• https://www.pcisecuritystandards.org/security_standards/documents.php (PCI
DSS v2.0 is starting point, v3.0 released Nov 2013)
• http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
• https://www.owasp.org/index.php/Main_Page (See oWASP Top 10)
• http://sqlandy.com/2013/07/the-sqlandy-rules-for-storing-credit-card-numbers/
• Books
•
•
•
•
PCI Compliance, Third Edition
Logging & Log Management (not SQL specific)
Securing SQL Server, Second Edition by Denny Cherry
Security Engineering (2nd edition is available free online)
• Blogs
•
•
•
•
•
Brian Kelley (Brian Kelley)
SQLSecurity.com
SecuringSQLServer.Com (Denny Cherry)
PCIGuru
Branden Williams
Contact Me
• Connect with me on LinkedIn at
www.linkedin.com/in/sqlandy
• I’m occasionally on Twitter as @SQLAndy
• I blog at www.sqlandy.com
• I live in Orlando – if you’re in the area let’s do lunch
Glossary
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PCI – Payment Card Industry
DSS – Data Security Standard
PAN – Primary Account Number
CDE – Cardholder Data Environment
QSA – Qualified Security Assessor
AOC – Attestation of Compliance, the formal filing with acquiring bank
each year
Compensating Control – One or more measures used to offset a
compliance gap, cannot be another control
ASV – Approved Scanning Vendor
Exception – Minor but documented deviation from any internal policy
or process, typically approved by compliance
Scope – the systems and processes that must meet PCI requirements
ROC – Report on Compliance
PII – Personally Identifiable Information
EFS – Encrypting File System
TDE – Transparent Database Encryption