How PCI And PA DSS will change enterprise applications

1,329 views
1,278 views

Published on

Webinar: How PCI and PA DSS Will Change Enterprise Applications, given by Ben Rothke CISSP PCI QSA and Sushila Nair, CISSP PCI QSA of BT PS.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,329
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
56
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

How PCI And PA DSS will change enterprise applications

  1. 1. Page How PCI and PA DSS Will Change Enterprise Applications Presented by: Ben Rothke, CISSP PCI QSA and Sushila Nair, CISSP PCI QSA November 25, 2008
  2. 2. Agenda <ul><li>Overview of application security and its need </li></ul><ul><li>PCI and Application Security </li></ul><ul><li>PCI Application Security Requirements </li></ul><ul><li>Application Security Action Items </li></ul><ul><li>Closing comments </li></ul>Page
  3. 3. About Ben <ul><li>Senior Security Consultant – BT Professional Services </li></ul><ul><li>Certifications: CISSP, CISM, CISA, PCI QSA, SITA </li></ul><ul><li>IT sector since 1988 / Information security since 1994 </li></ul><ul><li>Frequent writer and speaker </li></ul><ul><li>Author of Computer Security: 20 Things Every Employee Should Know (McGraw-Hill 2006) </li></ul>Page
  4. 4. About Sushila <ul><li>Product Manager - BT Professional Services </li></ul><ul><li>Certifications: CISM, CISPP, PCI QSA, BSI 17799 Lead Auditor </li></ul><ul><li>IT Sector since 1986 and security since 1995 </li></ul><ul><li>Frequent writer and speaker </li></ul>Page
  5. 5. PCI Data Security Standard <ul><li>Version 1.0 - January 2005 </li></ul><ul><li>1.1 – September 2006 </li></ul><ul><li>1.2 – October 2008 </li></ul><ul><li>Impacts ALL who </li></ul><ul><ul><li>Process </li></ul></ul><ul><ul><li>Transmit </li></ul></ul><ul><ul><li>Store: cardholder data </li></ul></ul><ul><li>Developed by MasterCard and Visa, endorsed by other brands </li></ul><ul><li>Worldwide reach </li></ul>Page
  6. 6. PCI DSS Page Build and Maintain A Secure Network 1. Install and maintain a firewall configuration to protect data 2. Do not use vendor supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored data 4. Encrypt transmission of cardholder data and sensitive information across public networks Maintain A Vulnerability Management Program 5. Use and regularly update antivirus software 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures 7. Restrict access to data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes Maintain an Information Security Policy 12. Maintain a policy that addresses information security
  7. 7. Software security is essential <ul><li>Software is the virtual equivalent of real-world infrastructure, yet there are no safeguards that the software we all depend upon is secure. </li></ul><ul><li>Growing number of global organizations and experts believe the enterprise is at great risk because the simplest application sitting on a user’s laptop can be an entry point for a potentially devastating hack or worm. </li></ul><ul><li>Because security is often retrofitted at the end of the SDLC as a response to a threat or after an exposure, higher production costs and delays can result. </li></ul><ul><li>Relative cost of fixing defects in production is as much as 100 times more expensive than if proper security had been implemented during the design phase. </li></ul>Page
  8. 8. The threats are real and constantly occur <ul><li>DSW Shoe Warehouse customer database hacked </li></ul><ul><ul><li>1.4 million records stolen </li></ul></ul><ul><li>FTC fines Choice Point $10 million for failure to protect consumer data. </li></ul><ul><li>TJ MAXX results in several states introducing new legislation to protect cardholder data. </li></ul><ul><li>Card Systems International forced to sell operations at a loss. </li></ul><ul><li>Ongoing compromises are driving changes in the DSS to include dual factor authentication and wireless security. </li></ul>Page
  9. 9. Nearly every web application is vulnerable <ul><li>70% of websites at immediate risk of being hacked! </li></ul><ul><li>- Accunetix – Jan 2007 http://www.acunetix.com/news/security-audit-results.htm </li></ul><ul><li>“ 8 out of 10 websites vulnerable to attack” - WhiteHat “security report – Nov 2006” https://whitehatsec.market2lead.com/go/whitehatsec/webappstats1106 </li></ul><ul><li>“ 75 percent of hacks happen at the application.” - Gartner “Security at the Application Level” </li></ul><ul><li>“ 64 percent of developers are not confident in their ability to write secure applications.” </li></ul><ul><li>- Microsoft Developer Research </li></ul>Page
  10. 10. ISC 2 CSSLP <ul><li>CSSLP ( Certified Secure Software Lifecycle Professional ) is ISC 2 newest certification </li></ul><ul><li>Designed to validate secure software development knowledge and best practices. </li></ul><ul><li>Takes a holistic approach to security in software and is intended to address the increasing number of application vulnerabilities that arise during the SDLC. </li></ul>Page
  11. 11. CSSLP Common Body of Knowledge (CBK) <ul><li>Secure Software Concepts </li></ul><ul><ul><li>security implications in software development </li></ul></ul><ul><li>Secure Software Requirements </li></ul><ul><ul><li>capturing security requirements in the requirements gathering phase </li></ul></ul><ul><li>Secure Software Design </li></ul><ul><ul><li>translating security requirements into application design elements </li></ul></ul><ul><li>Secure Software Implementation/Coding </li></ul><ul><ul><li>unit testing for security functionality and resiliency to attack, and developing secure code and exploit mitigation </li></ul></ul><ul><li>Secure Software Testing </li></ul><ul><ul><li>integrated QA testing for security functionality and resiliency to attack </li></ul></ul><ul><li>Software Acceptance </li></ul><ul><ul><li>security implication in the software acceptance phase </li></ul></ul><ul><li>Software Deployment, Operations, Maintenance and Disposal </li></ul><ul><ul><li>security issues around steady state operations and management of software </li></ul></ul>Page
  12. 12. The future of software Page Ingredients: Sun Java 1.5 runtime, Sun J2EE 1.2.2, Jakarta log4j 1.5, Jakarta Commons 2.1, Jakarta Struts 2.0, Harold XOM 1.1rc4, Hunter JDOMv1 Software Facts Modules 155 Modules from Libraries 120 % Vulnerability* * % Vulnerability values are based on typical use scenarios for this product. Your Vulnerability Values may be higher or lower depending on your software security needs: Cross Site Scripting 22 65 % SQL Injection 2 Buffer Overflow 5 Total Security Mechanisms 3 Encryption 3 Authentication 15 95 % Modularity .035 Cyclomatic Complexity 323 Access Control 3 Input Validation 233 Logging 33 Expected Number of Users 15 Typical Roles per Instance 4 Reflected 12 Stored 10 Cross Site Scripting Less Than 10 5 Reflected Less Than 10 5 Stored Less Than 10 5 SQL Injection Less Than 20 2 Buffer Overflow Less Than 20 2 Security Mechanisms 10 14 Encryption 3 15 Usage Intranet Internet Created by Jeff Williams of OWASP
  13. 13. PCI DSS requirement 6.6 <ul><li>Ensure that all web-facing applications are protected against known attacks by applying either of the following methods: </li></ul><ul><li>Option 1: Have all custom application code reviewed for common vulnerabilities by an organization that specializes in application security </li></ul><ul><li>Option 2: Install an application layer firewall in front of web-facing applications </li></ul><ul><li>To be compliant, either option must result in prevention of attacks. </li></ul>Page
  14. 14. PCI Council clarification of 6.6 <ul><li>Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats” </li></ul><ul><ul><li>Manual review of application source code </li></ul></ul><ul><ul><li>Proper use of automated application source code analyzer (scanning) tools </li></ul></ul><ul><ul><li>Manual web application security vulnerability assessment </li></ul></ul><ul><ul><li>Proper use of automated web application security vulnerability assessment (scanning) tools </li></ul></ul><ul><ul><li>Source: https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf </li></ul></ul>Page
  15. 15. Application firewall recommended capabilities <ul><li>Meet all applicable PCI DSS requirements pertaining to system components </li></ul><ul><li>Protect against the OWASP Top Ten (Requirement 6.5) </li></ul><ul><li>Inspect web application input and respond (allow, block, alert, log) based on active policy or rules </li></ul><ul><li>Prevent data leakage (inspect web application output and respond </li></ul><ul><li>Enforce both positive (“white list”) and negative (“black list”) security models. </li></ul>Page
  16. 16. Additional application firewall recommended capabilities <ul><li>Inspect both web page content, such as HTML, DHTML, and CSS, and the underlying protocols that deliver content, such as HTTP/S. </li></ul><ul><li>Inspect web services messages, if web services are exposed to the public Internet. (SOAP, XML, etc) </li></ul><ul><li>Inspect any protocol or data construct (proprietary or standardized) that is used to transmit data to or from a web application. </li></ul><ul><li>Defend against threats that target the WAF itself. </li></ul><ul><li>Support SSL and/or TLS termination, or be positioned such that encrypted transmissions are decrypted before being inspected by the WAF. </li></ul>Page
  17. 17. Application Security Action Items <ul><li>Update POS Applications </li></ul><ul><li>Identify Poorly Coded Web Apps </li></ul><ul><li>Perform Quarterly Vulnerability Scans </li></ul><ul><li>Perform Annual Penetration Testing </li></ul><ul><li>Create formal SDLC Processes </li></ul>Page
  18. 18. The Challenge <ul><li>Functionality versus security </li></ul><ul><li>Finding vulnerabilities </li></ul><ul><li>Managing changes </li></ul><ul><li>Understanding when there has been a breach </li></ul><ul><li>Knowledge </li></ul>
  19. 19. Application requirements within PCI DSS <ul><li>6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines </li></ul><ul><li>6.6 1) Reviews of applications via manual or automated vulnerability assessment tools or methods, or </li></ul><ul><li>2)Installing an application-layer firewall in front of public-facing web applications. </li></ul><ul><li>11.3 Perform penetration testing </li></ul>
  20. 20. Understanding where the greatest risks are <ul><li>Half of all account compromises are a result of web-application data breaches </li></ul><ul><li>90% of web application data compromises are a result of the top 5 -10 web-application vulnerabilities  </li></ul><ul><li>Most vulnerabilities are trivially exploitable </li></ul>
  21. 21. Manual Code review <ul><li>Review fewer than 200 - 400 lines of code at a time </li></ul><ul><li>Aim for an inspection rate of less than 300 - 500 LOC per hour </li></ul><ul><li>Take enough time for a proper, slow review, but not more than 60 - 90 minutes. </li></ul><ul><li>Authors should annotate source code before the review begins. </li></ul><ul><li>Checklists substantially improve results for both authors and reviewers. </li></ul><ul><li>Extracted from http://smartbear.com </li></ul>
  22. 22. Key Security Devices <ul><li>IPS/IDS </li></ul><ul><li>Firewalls </li></ul><ul><li>Vulnerability scanners </li></ul><ul><li>Web Application Firewalls </li></ul><ul><li>Database application Monitoring </li></ul>
  23. 23. Application development <ul><li>Develop secure code </li></ul><ul><ul><li>SDLC </li></ul></ul><ul><ul><li>Code Review </li></ul></ul><ul><li>Understand your vulnerabilities </li></ul><ul><ul><li>Penetration tests </li></ul></ul><ul><ul><li>WAS </li></ul></ul><ul><li>Remediate and protect </li></ul><ul><ul><li>Test and test again </li></ul></ul><ul><ul><li>Web application Firewall </li></ul></ul><ul><li>Monitor </li></ul><ul><ul><li>No one is infallible </li></ul></ul>
  24. 24. Q/A - Thank you for attending / contact information <ul><li>Ben Rothke, CISSP, QSA </li></ul><ul><li>Senior Security Consultant </li></ul><ul><li>BT Professional Services – http://bt.ins.com </li></ul><ul><li>New York, NY USA </li></ul><ul><li>[email_address] </li></ul>Page Sushila Nair Product Manager BT Professional Services – http://bt.ins.com New York, NY USA [email_address]

×