Page 1

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

Agenda

• Overview of application security and its need• PCI and Application Security• PCI Application Security Requirements • Application Security Action Items• Closing comments

Page 2

About Ben

• Senior Security Consultant – BT Professional Services

• Certifications: CISSP, CISM, CISA, PCI QSA, SITA• IT sector since 1988 / Information security

since 1994• Frequent writer and speaker• Author of Computer Security: 20 Things Every

Employee Should Know (McGraw-Hill 2006)

Page 3

About Sushila

• Product Manager - BT Professional Services• Certifications: CISM, CISPP, PCI QSA, BSI 17799

Lead Auditor• IT Sector since 1986 and security since 1995• Frequent writer and speaker

Page 4

PCI Data Security Standard

• Version 1.0 - January 2005• 1.1 – September 2006• 1.2 – October 2008• Impacts ALL who

• Process• Transmit• Store: cardholder data

• Developed by MasterCard and Visa, endorsed by other brands

• Worldwide reach

Page 5

PCI DSS

Page 6

Build and MaintainA Secure Network

1. Install and maintain a firewall configuration to protect data2. Do not use vendor supplied defaults for system passwords

and other security parameters

Protect Cardholder Data

3. Protect stored data4. Encrypt transmission of cardholder data and sensitive

information across public networks

Maintain A Vulnerability Management Program

5. Use and regularly update antivirus software6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to data by business need-to-know8. Assign a unique ID to each person with computer access9. Restrict physical access to cardholder data

Regularly Monitorand 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

Software security is essential

• Software is the virtual equivalent of real-world infrastructure, yet there are no safeguards that the software we all depend upon is secure.

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

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

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

Page 7

The threats are real and constantly occur

• DSW Shoe Warehouse customer database hacked• 1.4 million records stolen

• FTC fines Choice Point $10 million for failure to protect consumer data.

• TJ MAXX results in several states introducing new legislation to protect cardholder data.

• Card Systems International forced to sell operations at a loss.

• Ongoing compromises are driving changes in the DSS to include dual factor authentication and wireless security.

Page 8

Nearly every web application is vulnerable

• 70% of websites at immediate risk of being hacked!

- Accunetix – Jan 2007 http://www.acunetix.com/news/security-audit-results.htm

• “8 out of 10 websites vulnerable to attack” -

WhiteHat “security report – Nov 2006” https://whitehatsec.market2lead.com/go/whitehatsec/webappstats1106

• “75 percent of hacks happen at the application.” - Gartner “Security at the Application Level”

• “64 percent of developers are not confident in their ability to write secure applications.”

- Microsoft Developer Research

Page 9

ISC2 CSSLP

• CSSLP (Certified Secure Software Lifecycle Professional) is ISC2 newest certification

• Designed to validate secure software development knowledge and best practices.

• Takes a holistic approach to security in software and is intended to address the increasing number of application vulnerabilities that arise during the SDLC.

Page 10

CSSLP Common Body of Knowledge (CBK)

• Secure Software Concepts• security implications in software development

• Secure Software Requirements• capturing security requirements in the requirements gathering phase

• Secure Software Design• translating security requirements into application design elements

• Secure Software Implementation/Coding• unit testing for security functionality and resiliency to attack, and developing

secure code and exploit mitigation

• Secure Software Testing• integrated QA testing for security functionality and resiliency to attack

• Software Acceptance• security implication in the software acceptance phase

• Software Deployment, Operations, Maintenance and Disposal

• security issues around steady state operations and management of software

Page 11

The future of software

Page 12

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 2Buffer 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 15Typical Roles per Instance 4

Reflected 12

Stored 10

Cross Site Scripting Less Than 10 5 Reflected Less Than 10 5 Stored Less Than 10 5SQL Injection Less Than 20 2Buffer Overflow Less Than 20 2Security Mechanisms 10 14 Encryption 3 15

Usage Intranet Internet Created by Jeff Williams of OWASP

PCI DSS requirement 6.6

Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:Option 1: Have all custom application code reviewed for common vulnerabilities by an organization that specializes in application security

Option 2: Install an application layer firewall in front of web-facing applications

•To be compliant, either option must result in prevention of attacks.

Page 13

PCI Council clarification of 6.6

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”

1. Manual review of application source code

2. Proper use of automated application source code analyzer (scanning) tools

3. Manual web application security vulnerability assessment

4. Proper use of automated web application security vulnerability assessment (scanning) tools

Source: https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf

Page 14

Application firewall recommended capabilities

• Meet all applicable PCI DSS requirements pertaining to system components

• Protect against the OWASP Top Ten (Requirement 6.5)

• Inspect web application input and respond (allow, block, alert, log) based on active policy or rules

• Prevent data leakage (inspect web application output and respond

• Enforce both positive (“white list”) and negative (“black list”) security models.

Page 15

Additional application firewall recommended capabilities

• Inspect both web page content, such as HTML, DHTML, and CSS, and the underlying protocols that deliver content, such as HTTP/S.

• Inspect web services messages, if web services are exposed to the public Internet. (SOAP, XML, etc)

• Inspect any protocol or data construct (proprietary or standardized) that is used to transmit data to or from a web application.

• Defend against threats that target the WAF itself.• Support SSL and/or TLS termination, or be positioned

such that encrypted transmissions are decrypted before being inspected by the WAF.

Page 16

Application Security Action Items

1. Update POS Applications2. Identify Poorly Coded Web Apps3. Perform Quarterly Vulnerability Scans 4. Perform Annual Penetration Testing5. Create formal SDLC Processes

Page 17

The Challenge

1. Functionality versus security2. Finding vulnerabilities3. Managing changes4. Understanding when there has been a breach5. Knowledge

18

Application requirements within PCI DSS

6.5 Develop all web applications based on secure coding guidelines such as the Open WebApplication Security Project guidelines

6.6 1) Reviews of applications via manual or automated vulnerability assessment tools or methods, or

2)Installing an application-layer firewall in front of public-facing web applications.

11.3 Perform penetration testing

19

Understanding where the greatest risks are

• Half of all account compromises are a result of web-application data breaches

• 90% of web application data compromises are a result of the top 5 -10 web-application vulnerabilities 

• Most vulnerabilities are trivially exploitable

20

Manual Code review

• Review fewer than 200 - 400 lines of code at a time

• Aim for an inspection rate of less than 300 - 500 LOC per hour

• Take enough time for a proper, slow review, but not more than 60 - 90 minutes.

• Authors should annotate source code before the review begins.

• Checklists substantially improve results for both authors and reviewers.

Extracted from http://smartbear.com

21

22

Key Security Devices

• IPS/IDS

• Firewalls

• Vulnerability scanners

• Web Application Firewalls

• Database application Monitoring

Application development

• Develop secure code– SDLC– Code Review

• Understand your vulnerabilities– Penetration tests– WAS

• Remediate and protect– Test and test again– Web application Firewall

• Monitor– No one is infallible

23

Q/A - Thank you for attending / contact information

Page 24

Ben Rothke, CISSP, QSASenior Security ConsultantBT Professional Services – http://bt.ins.com New York, NY USAben.rothke@bt.com

Sushila NairProduct ManagerBT Professional Services – http://bt.ins.com New York, NY USAsushila.nair@bt.com