Presentation is loading. Please wait.

Presentation is loading. Please wait.

Credit Card Security for the SQL DBA Andy Warren.

Similar presentations

Presentation on theme: "Credit Card Security for the SQL DBA Andy Warren."— Presentation transcript:

1 Credit Card Security for the SQL DBA Andy Warren

2 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

3 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

4 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

5 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)

6 The 12 Core Requirements of PCI

7 Sub-Requirement Example

8 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

9 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)

10 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

11 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

12 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

13 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

14 Logging PCI requires 90 days online, 12 months available Required for forensics and alerting Typically a combination of many different types of logs

15 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

16 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

17 FTP Basically evil, don’t use it, even if the file is encrypted

18 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

19 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!

20 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

21 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

22 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

23 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

24 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.

25 Resources Web Reading (PCI DSS v2.0 is starting point, v3.0 released Nov 2013) (PCI DSS v2.0 is starting point, v3.0 released Nov 2013) (See oWASP Top 10) (See oWASP Top 10) Books PCI Compliance, Third Edition Logging & Log Management (not SQL specific)Logging & Log Management (not SQL specific) Securing SQL Server, Second Edition by Denny CherrySecuring SQL Server, Second Edition by Denny Cherry Security Engineering (2 nd edition is available free online) Security Engineering (2 nd edition is available free online) Blogs Brian Kelley (Brian Kelley) Brian Kelley (Brian Kelley) SecuringSQLServer.Com (Denny Cherry) SecuringSQLServer.Com (Denny Cherry) PCIGuru Branden Williams

26 Contact Me Connect with me on LinkedIn at I’m occasionally on Twitter as @SQLAndy I blog at I live in Orlando – if you’re in the area let’s do lunch

27 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

Download ppt "Credit Card Security for the SQL DBA Andy Warren."

Similar presentations

Ads by Google