Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PCI DSS-based Security: Is This For Real? by Dr. Anton Chuvakin


Published on

PCI DSS-based Security: Is This For Real? Using PCI DSS as A Foundation for Your Security Program

Published in: Technology
  • Be the first to comment

PCI DSS-based Security: Is This For Real? by Dr. Anton Chuvakin

  1. 1. PCI DSS-based Security: Is This For Real?Using PCI DSS as A Foundation for Your Security Program<br />Dr. Anton Chuvakin<br />Author of “PCI Compliance”<br /><br />Security Warrior Consulting<br /><br />Secure 360, Minneapolis, MN<br />May 2010<br />
  2. 2. Inspiration….<br />“Too many have lost sight of goal which is to reduce the risk of security breaches and card fraud. Assessors often just focus on the words in the standard. They do not understand WHY the standard was written, or the risk built into it. “<br />PCI Knowledge Base by late David Taylor<br />
  3. 3. “PCI Is The Devil !!!”<br />
  4. 4. Outline<br />What is PCI DSS? Why it is here?<br />PCI DSS as a security framework<br />PCI DSS as a data security framework<br />Starting from PCI: how to do it?<br />Risks and pitfalls<br />
  5. 5. What is PCI DSS or PCI?<br />Payment Card Industry Data Security Standard<br />Payment Card = <br />Payment Card Industry = <br />Data Security = <br />Data Security Standard = <br />
  6. 6. PCI Data Security Standard<br />PCI Council publishes PCI DSS –Data Security Standard<br />Outlined the minimumdata security protections measures for payment card data.<br />Defined Merchant & Service Provider Levels, and compliance validation requirements.<br />Left the enforcement to card brands (Council doesn’t fine anybody!)<br />Key point: PCI DSS (document) vs PCI (validation regime)<br />
  7. 7. PCI Game: The Players<br />PCI Security Standards Council<br />
  8. 8. My Data – Their Risk!?<br />*I* GIVE *YOU* DATA<br />*YOU* LOSE IT<br />*ANOTHER* SUFFERS!<br />
  9. 9. <ul><li>Install and maintain a firewall confirmation to protect data
  10. 10. Do not use vendor-supplied defaults for system passwords and other security parameters</li></ul>Build and Maintain a Secure Network<br /><ul><li>Protect stored data
  11. 11. Encrypt transmission of cardholder data and sensitiveinformation across public networks</li></ul>Protect Cardholder Data<br /><ul><li>Use and regularly update anti-virus software
  12. 12. Develop and maintain secure systems and applications</li></ul>Maintain a Vulnerability Management Program<br /><ul><li>Restrict access to data by business need-to-know
  13. 13. Assign a unique ID to each person with computer access
  14. 14. Restrict physical access to cardholder data</li></ul>Implement Strong Access Control Measures<br /><ul><li>Track and monitor all access to network resources and cardholder data
  15. 15. Regularly test security systems and processes</li></ul>Regularly Monitor and Test Networks<br /><ul><li>Maintain a policy that addresses information security</li></ul>Maintain an Information Security Policy<br />PCI Data Security Standard In-Depth<br />
  16. 16. PCI DSS Coverage<br />… in no particular order:<br />Security policy and procedures<br />Network security<br />Malware protection<br />Application security (and web)<br />Vulnerability scanning and remediation<br />Logging and monitoring<br />Security awareness<br />
  17. 17. PCI DSS With No Cards?<br />
  18. 18. PCI Coverage: What Do We Learn?<br />Focus: confidentiality credit of card data…<br />… but not exactly: data avoidance is even better!<br />Now …<br />… a hard question: what is “a good security program”? <br />What technology, processes, etc?<br />What are the goals?<br />What are the metrics?<br />
  19. 19. Our Goals!<br />
  20. 20. Holes?<br />BIG HOLE#1 Everything availability<br />“If your payment app blows up, it magically becomes ‘PCI compliant’” <br />HOLE #2 Everything productivity<br />Spam, web filtering, client protection, etc<br />HOLE #3 Card data discovery<br />PCI assumes omniscient data owners…<br />
  21. 21. Sidetrack: WTH is “Data Security”<br />… back to <br />If you router is 0wned, is data security still achieved?<br />If a secondary system is compromised?<br />QA machine?<br />Public web server?<br />Know any “data idiots?”<br />
  22. 22. Pros and Cons<br />Pros:<br />Good coverage of many domains (tech and process)<br />Useful focus on data elimination, app security and monitoring<br />Detailed guidance available<br />A lot of tools available to help<br />Lacks complexity of ISO, NIST, etc<br />Cons:<br /><ul><li>Does not start from policy (but you can!)
  23. 23. Holes!
  24. 24. Lack of logical structure (but Prioritized Approach is there)
  25. 25. Your risk not covered
  26. 26. “Kill the data” focus doesn’t apply to some
  27. 27. Measuring success?!</li></li></ul><li>Pause…<br />What do you think?<br />
  28. 28. OK, Diving In…<br />
  29. 29. Phase 1 Understanding<br />Read PCI DSS and Prioritized Approach<br />Organize into domains<br />Split technology requirements from process/policy/procedure<br />Mind the holes!<br />Also: think about other regulations, e.g. breach disclosure laws<br />
  30. 30. Holes? What Holes?<br />
  31. 31. Phase 2 Plan<br />Gaps?<br />Policy/process gap<br />Technology gap<br />Anything to buy? Build? Outsource?<br /> “Close the gap” strategy<br />Guidance: PCI SSC “Prioritized Approach”<br />“Reverse PCI”: start from Req 12 “Policy “<br />Coordinate with stakeholders<br />
  32. 32. Scope Explodes!<br />Key lesson in PCI compliance: <br />SHRINK THE SCOPE! “Drop the data”<br />Here we expand the scope to all data and even all systems.<br />
  33. 33. Phase 3 Do it!<br />Following the prioritized plan, start building <br />If under actual PCI regime, start from payment networks [of course!]<br />Adjust! You are not “praying to PCI gods”<br />Q: Can I use ISO27001 instead?<br />A: Sure, but you would not be reading this if you had this choice!<br />
  34. 34. Done?<br />
  35. 35. Phase 4 Run it!<br />Ongoing tasks in PCI:<br />
  36. 36. Success? Success!!!<br />Measure success<br />Metrics system<br />No assessment prep (no QSA) – but do self-assess! (INPUTS)<br />Incident and loss reduction (OUTPUTS)<br />Document – as if for QSA!<br />“Compliance is validated security”<br />
  37. 37. Key Issue<br />Q: Which one of these guarantees that you will never suffer a motorcycle accident?<br />A: Having “a helmet law” on the books<br />B. Being aware of the above law<br />C. Always wearing a basic helmet<br />D. Always wearing an advanced, “market leading” helmet<br />
  38. 38. Answer!<br />E. NONE OF THE ABOVE!<br />
  39. 39. Why Are We Doing It?<br />Risk of DEATH<br />Vs <br />Risk of $60 fine?<br />
  40. 40. Conclusions<br />What we have achieved here?<br />Likely, became PCI compliant<br />Evaluated PCI as a foundation for security<br />Built a security program<br />Started operational processes<br />Helped protect data, systems and other valuable information assets!<br />
  41. 41. In Other Words…<br />Every time you think “PCI DSS OR security,” <br />god kills a kitten!<br />
  42. 42. Questions?<br />Dr. Anton Chuvakin<br /><br />Google Voice: 510-771-7106 <br />Site:<br />Blog:<br />LinkedIn:<br />Twitter:@anton_chuvakin<br />
  43. 43. Get “PCI Compliance” Book!<br />Useful reference for merchants, vendors – and everybody else in “PCI realm”<br />Book released Dec 2009<br />Get two free chapters at <br /><br />
  44. 44. More on Anton<br />NOW: consultant<br />Book author: “Security Warrior”, “PCI Compliance”, “Information Security Management Handbook”, “Know Your Enemy II”, “Hacker’s Challenge 3”, etc<br />Conference speaker: SANS, FIRST, GFIRST, ISSA, CSI, Interop, many, many others worldwide<br />Standard developer: CEE, CVSS, OVAL, etc<br />Community role: SANS, Honeynet Project, WASC, CSI, ISSA, OSSTMM, InfraGard, ISSA, others<br />Past roles: Researcher, Security Analyst, Strategist, Evangelist, Product Manager<br />
  45. 45. Security Warrior Consulting Services<br />Logging and log management policy<br />Develop logging policies and processes, log review procedures, workflows and periodic tasks as well as help architect those to solve organization problems <br />Plan and implement log management architecture to support your business cases; develop specific components such as log data collection, filtering, aggregation, retention, log source configuration as well as reporting, review and validation<br />Customize industry “best practices” related to logging and log review to fit your environment, help link these practices to business services and regulations<br />Help integrate logging tools and processes into IT and business operations<br />Content development<br />Develop of correlation rules, reports and other content to make your SIEM and log management product more useful to you and more applicable to your risk profile and compliance needs<br />Create and refine policies, procedures and operational practices for logging and log management to satisfy requirements of PCI DSS, HIPAA, NERC, FISMA and other regulations<br />More at<br />