Latin ISRM EFFECTIVE APPLICATION SECURITY STRATEGY FOR MANAGING ONGOING PCI-DSS 2.0 COMPLIANCE ASHIT DALAL, PCI-DSS QSA, CRISC, CGEIT, CISM, CISA, CSSA, CPEA Sr. Manager & Managing Consultant K3DES LLC, NJ (USA) EMAIL: ashit.dalal@k3des.com October 2011
DISCLAIMER The slides in the presentation are my personal views and experience and based on the publicly available information and not the views of or binding on my organization in any way. The presentation is purely for education, awareness and training through ISACA.
AGENDA Brief overview of Application Security and OWASP top 10 Security Threats Brief overview of Challenges and Concerns for securing Applications in conventional Client server and/or Cloud computing / Virtualized Environment Brief Introduction to PCI-DSS (V 2.0) Standard. Overview of key requirements under PCI-DSS V 2.0 with regard to Application Security Review of Effective strategy and control measures for securing Applications in conventional and/or Cloud / Virtualized Environment Analysis & Review of various Application Security methods / tools namely Source Code Review, Web Application Firewall and Web Application Scanner to comply with PCI-DSS requirements. Summary Q & A and Discussion
Innocent Code
State of Web Application Security A critical discipline within a sound overall IT strategy & Security practice. Existing physical & network security policies, products, point solutions and controls are not sufficient to meet the security needs of the enterprise. Open Web Application Security Project (OWASP) is dedicated to helping build secure Web applications. Finding the right mix of Experience and Methodology
New realities & requirements for Web Services Security Most security violations come from within the Firewall. Vulnerable Applications have contributed to almost 90% of recent breaches. Mission-critical initiatives (e.g. PCI-DSS, PA-DSS) often need cross-firewall access & integration. Ports that were originally intended to pass very specific protocols are now being used for many purposes. XML Web services Simple Object Access Protocol (SOAP) messages were specifically designed to easily pass through existing firewalls by being carried out transport protocols like HTTP, SMTP etc. Source: XML Web Services Security Forum
Application Security Is the Trend of the Future The biggest vulnerability to a corporation s network is its widespread access to its applications. Security has focused on anti-virus and network security but the most crucial part of business transaction is the application and its core data. -- Curtis Coleman, CISSP, Kick-off of new Application Assurance Department, 2001 3 rd Age Age of Application Security 2 nd Age Age of Network Security 1 st Age Age of Anti-Virus (Source: OWASP San Jose Chapter) 7
Business Impact of Application Security Defects Bad Business On average, there are 5 to 15 defects in every 1,000 lines of code US Dept. of Defense and the Software Engineering Institute Slow Business It takes 75 minutes on average to track down one defect. Fixing one of these defects takes 2 to 9 hours each 5 Year Pentagon Study Researching each of the 4,200 vulnerabilities published by CERT in 2003-2004 for 10 minutes would have required 1 staffer to research for 17.5 full workweeks or 700 hours Intel White paper, CERT, ICSA Labs Loss of Business A company with 1,000 servers can spend $300,000 to test & deploy a patch; most companies deploy several patches a week Gartner Group
Existing Point Security Solutions are not enough Traditional vulnerability scanners scan web servers but not web applications. Manual Pen test is effective but is not scalable & does not focus on remediation. Traditional Network Firewalls cannot offer protection against sophisticated attacks targeted on Web Applications. (Web) Application security strategy also needs Riskbased approach comprising, People, Processes and Technology for effective protection against targeted attacks
Why isn t the Web Environment secure? SSL and Data-encryption are not enough They protect the information during transmission, but when this data is used by the system it must be in a readable form Odds are the data is not stored in an encrypted format It is surprisingly easy to retrieve data from many Web-based applications Conventional Firewalls are not enough Ports 80 and 443 pass completely through the firewall (Source: OWASP San Jose Chapter) 10
But, I have a firewall... Source: Jeremiah Grossman, BlackHat 2001 11
OK, but I use encryption... Source: Jeremiah Grossman, BlackHat 2001 12
Your Code is Part of Your Security Perimeter Application Layer APPLICATION ATTACK Your security perimeter has huge holes at the application layer Custom Developed Application Code Billing Human Resrcs Directories Web Services Legacy Systems Databases Network Layer Fi re w al l App Server Web Server Hardened OS You can t use network layer protection (firewall, SSL, IDS, hardening) to stop or detect application layer attacks Fi re w al l
Security across entire SDLC 80% of vulnerabilities are found in the source code of the application rather than the Web server or application configuration. (Ref: HP). Traditional approach of having a siloed security team finishing testing on Web Application and report the vulnerabilities to the Development teams is being replaced by more holistic and robust approach that spans across entire SDLC process. It is a team based and risk-driven approach where Development teams, QA teams and Security teams work together to build robust Applications.
System Development Lifecycle (SDLC) Security Checkpoints 15
OWASP Top Ten (2010 Edition) http://www.owasp.org/index.php/top_10
WHAT DOES OWASP TOP 10 MEAN? TYPE OF VULNERABILITY BRIEF DEFINITION TYPICAL IMPACT A1 - INJECTION Tricking an application into including unintended commands in the data sent to an interpreter Usually severe. Entire database can usually be read or modified May also allow full database schema, or account access, or even OS level access A2- CROSS SITE SCRIPTING Raw data from attacker is sent to an innocent user s browser. Exploiting user s trust into a Website Steal user s session, steal sensitive data, rewrite web page, redirect user to phishing or malware site A3-BROKEN AUTHENTICATION & SESSION MGT. A4-INSECURE DIRECT OBJECT REFERENCE Flaws in Broken Authentication & Session Management most frequently involve the failure to protect credentials and session tokens through their lifecycle Failure to enforce proper Authorization User accounts compromised or user sessions hijacked Users are able to access unauthorized files or data A5- CROSS SITE REQUEST FORGERY (CSRF) An attack where the victim s browser is tricked into issuing a command to a vulnerable web application. Vulnerability is caused by browsers automatically. Exploiting Website s trust into the User. Initiate transactions (transfer funds, logout user, close account) Access sensitive data Change account details
TYPE OF VULNERABILITY BRIEF DEFINITION TYPICAL IMPACT WHAT DOES OWASP TOP 10 MEAN? A6 SECURITY MISCONFIGURATION Misconfiguration of any component from the OS up through the App Server Backdoor entry through missing OS or server patch XSS flaw exploits due to missing application framework patches Unauthorized access to default accounts, application functionality or data, or unused but accessible functionality due to poor server configuration A7- INSECURE CRYPTOGRAPHIC STORAGE Failure to identify all sensitive data Failure to identify all the places that this sensitive data gets stored e.g. Databases, files, directories, log files, backups, etc. Failure to properly protect this data in every location Attackers access or modify confidential or private information e.g., credit cards, health care records, financial data etc. Attackers extract secrets to use in additional attacks Company embarrassment, customer dissatisfaction, and loss of trust Expense of cleaning up the incident, such as forensics, sending apology letters, reissuing thousands of credit cards, providing identity theft insurance Business gets sued and/or fined (e.g. TJ Maxx)
WHAT DOES OWASP TOP 10 MEAN? TYPE OF VULNERABILITY BRIEF DEFINITION TYPICAL IMPACT A8- FAILURE TO RESTRICT URL ACCESS Inadequate enforcement of proper authorization, along with A4 Insecure Direct Object References Attackers invoke functions and services they re not authorized for Access other user s accounts and data Perform privileged actions A9-INSUFFICIENT TRANSPORT LAYER PROTECTION Failure to identify all sensitive data Failure to identify all the places that this sensitive data is sent e.g. On the web, to backend databases, to business partners and so on. Failure to properly protect this data in every location Attackers access or modify confidential or private information Attackers extract secrets to use in additional attacks Company embarrassment, customer dissatisfaction, and loss of trust Expense of cleaning up the incident Business gets sued and/or fined A10- UNVALIDATED REDIRECTS & FORWARDS Web Application can include user supplied parameters in the destination URL. If they aren t validated, attacker can send victim to a site of their choice Redirect victim to phishing or malware site. Attacker s request is forwarded past security checks, allowing unauthorized function or data access
Firewall Firewall Network Layer Application Layer Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Databases Legacy Systems Web Services Directories Human Resrcs Billing SQL Injection Example HTTP request APPLICATION ATTACK HTTP SQL response query Custom Code DB Table Account: "SELECT * FROM Account: Account Summary accounts SKU: WHERE acct= SKU: OR 1=1-- " Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293 1. Application presents a form to the attacker App Server Web Server 2. Attacker sends an attack in the form data 3. Application forwards attack to the database in a SQL query Hardened OS 4. Database runs query containing attack and sends encrypted results back to application 5. Application decrypts data as normal and sends results to the user
Cross-Site Scripting Example Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions 1 Attacker sets the trap update my profile Attacker enters a malicious script into a web page that stores the data on the server Application with stored XSS vulnerability 2 Victim views page sees attacker profile Custom Code Script runs inside victim s browser with full access to the DOM and cookies 3 Script silently sends attacker Victim s session cookie
Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions CSRF Example 1 Attacker sets the trap on some website on the internet (or simply via an e-mail) Hidden <img> tag contains attack against vulnerable site Application with CSRF vulnerability 2 While logged into vulnerable site, victim views attacker site <img> tag loaded by browser sends GET request (including credentials) to vulnerable site Custom Code 3 Vulnerable site sees legitimate request from victim and performs the action requested
Prevention / Detection of Additional Vulnerabilities In addition to OWASP, one needs to look at the following to have a comprehensive Application Security Strategy: 1) Application runtime configuration 2) Buffer Overflow 3) Web services 4) Malicious code 5) Customized cookies or hidden fields Source: IBM 23
What is the PCI DSS? The Payment Card Industry Data Security Standard (PCI DSS) is a global security program that was created to increase confidence in the payment card industry and reduce risks to PCI Members, Merchants, Service Providers and Consumers. https://www.pcisecuritystandards.org/pdfs/pcissc_overview.pdf
Who Must Comply? PCI data security requirements apply to all merchants and service providers that store, process or transmit any cardholder data. All organizations with access to cardholder information must meet the data security standards. However, the way in which organizations validate their compliance differs based on whether they are merchants or service providers and on specific validation requirements defined by each credit card brand. Each of the five major credit card companies has its own set of validation requirements. Information regarding service provider levels and validation requirements can be obtained from each individual credit card company s Web site. The security requirements apply to all system components, network components, servers or applications included in, or connected to, the processing of cardholder data. 25
Who does PCI DSS apply to? Any entity that stores, process and/or transmits cardholder data must comply with the PCI Data Security Standard (DSS). Entities may include, but are not limited to, merchants and service providers. Applies to: Retail (online & brick & mortar) Hospitality (restaurants, hotel chains, etc.) Transportation (i.e. airlines, car rental, etc.) Financial Services (banks, credit unions, card processors, brokerages, insurance, etc.) Energy (Oil, Gas, Utilities, etc), Healthcare/Education (hospitals, universities) Government (Federal, Provincial, Municipal) Not-For-Profit Organizations (Red Cross, churches, etc)
Key PCI DSS Requirements Build and Maintain a Secure Network 1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data sent across open, public networks Maintain a Vulnerability Management Program 5. Use and regularly update anti-virus software 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures 7. Restrict access to cardholder 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 Connected Entities and Contracts PCI DSS Ver. 1.1
Three Components to Compliance Program Compliance: The set of criteria to achieve compliance with the payment brand compliance program. All payment brands require compliance with the PCI DSS. Validation: The actions that an entity must take to validate that they are compliant. Validation requirements vary by payment brand and merchant/service provider level Reporting: The method of reporting the validation of compliance to the acquirer or payment brand Reporting requirements vary by payment brand and merchant/service provider level
PCI Compliance Trends and Tips PCI is not about securing sensitive data, it s about eliminating data altogether. John Kindervag, Forrester Analyst and former QSA
PCI Compliance Trends and Tips PCI SWALLOWS ITS OWN TAIL I m concerned that as long as the payment card industry is writing the standards, we ll never see a more secure system, (Rep. Bennie) Thompson said. We in Congress must consider whether we can continue to rely on industrycreated standards, particularly if they re inadequate to address the ongoing threat. http://information-security-resources.com/2009/04/01/payment-card-industry-swallows-itsown-tail
Recent Credit/ Debit Card breaches Citibank (June 2011) Sony Play station (May 2011) Michael s Store (Debit Cards) (May 2011) T. J. Max (January 2007) 45 Million Customers Heartland Systems, Princeton, NJ (Jan. 2009) Hannaford Brothers (March 2008) 4.2 Million Customers Card System Solutions (2005) 40 Million Customers
PCI-DSS requirements for developing & maintaining secure systems & applications Section 6 of PCI-DSS (Ver: 2.0) has key requirements for developing & maintaining secure systems & applications: 6.1 Implement an effective Patch Management process for protection from known vulnerabilities. 6.2 Establish process to identify & assign a risk ranking to newly discovered security vulnerabilities. (e.g. OWASP Top 10). 6.3 Develop software applications in accordance with PCI-DSS and industry based best practices. Incorporate Information Security through out the SDLC Process. 6.4 Implement an effective Change Management Process 6.5 Develop Applications based on Secure Coding guidelines. Prevent common coding vulnerabilities in SDLC Processes.
PCI-DSS requirements for developing & maintaining secure systems & applications 6.6 For public-facing Web applications, address new threats & vulnerabilities on an on-going basis & ensure these applications are protected from known vulnerabilities by: Conducting Vulnerability assessment (manual or by using automated tools) at least annually or after any changes. OR Installing a Web-application Firewall in front of public-facing web applications.
Identified Vulnerabilities under Section 6.5 of PCI-DSS Vulnerability Injection Flaws (e.g. SQL Injection, OS Command Injection, LDAP Injection etc.) Buffer overflow Insecure cryptographic storage Insecure communications Improper error handling Identify all High Vulnerabilities as required under Section 6.2 Cross-site Scripting Testing Procedure / Countermeasure Validate input to verify user data cannot modify meaning of commands & queries. Validate buffer boundaries & truncate input strings Prevent cryptographic flaws Properly encrypt all authenticated & sensitive communications Do not leak information via error messages Identification of all High vulnerabilities. This is currently the best practice but becoming a requirement from June 30, 2012 onwards Validate all parameters before inclusion, utilize context-sensitive escaping etc.
Identified Vulnerabilities under Section 6.5 of PCI-DSS Vulnerability Improper Access Control such as Insecure Object References, failure to restrict URL access & Directory traversal Cross-site request Forgery (CSRF) Testing Procedure / Countermeasure Proper Authentication of users and sanitize input. Do not reveal internal object references to users. Do not reply on authorization credentials and tokens automatically submitted through or by browsers.
PCI-DSS Requirement Section 6.6 Requirement 6.6 (as of June 30, 2008) Web application firewall or code review? It s your choice, but should they both be required?
Payment Application (PA-DSS) Time for another acronym Payment Application Data Security Standard (PA-DSS) PA-DSS, originally Visa s PABP program, is targeted at payment app vendors PA-DSS applies to the payment application software/hardware only Just because the application is compliant does not mean your systems are compliant PCI DSS applies to merchant networks & service providers Standalone Terminal POS System
Best Practices for Secure Code Development Develop Secure Code Follow the best practices in OWASP s Guide to Building Secure Web Applications http://www.owasp.org/index.php/guide Use OWASP s Application Security Verification Standard as a guide to what an application needs to be secure http://www.owasp.org/index.php/asvs Use standard security components that are a fit for your organization Use OWASP s ESAPI as a basis for your standard components http://www.owasp.org/index.php/esapi Review Your Applications Have an expert team review your applications Review your applications following OWASP Guidelines OWASP Code Review Guide: http://www.owasp.org/index.php/code_review_guide OWASP Testing Guide: http://www.owasp.org/index.php/testing_guide
CoBIT & Relevant Application Security Controls Plan and Organize Acquire & Impleme nt PO4 Define the IT Processes, Organization & relationships PO8 Manage Quality PO 9 Assess & Manage IT Risk AI 2 Acquire & maintain Application software AI 6 Manage changes (Change Management) AI 7 Install & accredit Solution & Changes Deliver & Support DS 5 Manage System Security DS 9 Manage the Configuration Monitor & Evaluate MI 3 Ensure compliance with external requirements (e.g. PCI-DSS)
(Vulnerability) Prevention v/s (Threat) Detection From PCI-DSS standpoint, Application Security Strategy can be deigned and implemented based on two main approaches: 1) Vulnerability Prevention Pro-active Prevention approach 2) Threat Detection Reactive Detection approach No Application security strategy can be considered effective without having a right balance of two approaches specific to Each organization according to threat, exposure and TCO considerations.
Major Techniques / Tools for implementing effective Application Security Strategy SOURCE CODE ANALYSIS- Preventive measure Source Code Analysis tools are designed to analyze the source code and /or complied version of code in order to help find security flaws. WEB APPLICATION FIREWALL- Detective measure A Web Application Firewall is a form of firewall which controls input,, output, and/or Access from, to, or by an application or service. It operates by monitoring and Potentially blocking the input, output, or system service calls which do not meet the Configured policy of the firewall. WEB APPLICATION SCANNER-Primarily Detective / (but can also be used as Preventive measure) A Web Application Scanner is program which communicates with a web application through the web front-end in order to identify potential security vulnerabilities in the web application and architectural weaknesses. It performs a black-box test.
EFFECTIVENESS OF VARIOUS TOOLS TYPE OF VULNERABILITY SOURCE CODE ANALYSIS WEB APPLICATION FIREWALL WEB APPLICATION SCANNER A1 - INJECTION EXCELLENT GOOD FAIR A2- CROSS SITE SCRIPTING EXCELLENT GOOD GOOD A3-BROKEN AUTHENTICATION & SESSION MGT. NOT EFFECTIVE ON ITS OWN NOT EFFECTIVE ON ITS OWN NOT EFFECTIVE ON ITS OWN A4-INSECURE DIRECT OBJECT REFERENCE A5- CROSS SITE REQUEST FORGERY (CSRF) EXCELLENT GOOD GOOD LIMITED UTILITY LIMITED UTILITY FAIR (NEEDS TO BE USED WITH MANUAL PEN TEST)
EFFECTIVENESS OF VARIOUS TOOLS (Contd..) TYPE OF VULNERABILITY SOURCE CODE ANALYSIS WEB APPLICATION FIREWALL WEB APPLICATION SCANNER A6 SECURITY MISCONFIGURATION A7- FAILURE TO RESTRICT URL ACCESS GOOD GOOD EXCELLENT FAIR FAIR FAIR A8-INSECURE CRYPTOGRAPHIC STORAGE GOOD NOT EFFECTIVE ON ITS OWN NOT EFFECTIVE ON ITS OWN A9-INSUFFICIENT TRANSPORT LAYER PROTECTION A10- UNVALIDATED REDIRECTS & FORWARDS GOOD GOOD GOOD FAIR GOOD FAIR
EFFECTIVENESS OF VARIOUS TOOLS (Contd..) TYPE OF VULNERABILITY SOURCE CODE ANALYSIS WEB APPLICATION FIREWALL WEB APPLICATION SCANNER B1-APPLICATION RUNTIME CONFIGURATION FAIR FAIR EXCELLENT B2-BUFFER OVERFLOW EXCELLENT FAIR FAIR B3-WEB SERVICES GOOD GOOD NOT EFFECTIVE B4- MALICIOUS CODE EXCELLENT NOT GOOD NOT GOOD B5- CUSTOMIZED COOKIES / HIDDEN FIELDS EXCELLENT EXCELLENT EXCELLENT
Why Use Web Application Firewalls? 1. Web applications deployed are generally insecure and conventional Firewalls do not provide adequate protection. 2. Developers should, of course, continue to strive to build better/more secure software. But in the meantime, System Admins must also support Defence-in-Depth approach. 3. Insecure applications aside, WAFs are an important building block in every HTTP network as they serve as an excellent detection & monitoring tool to support Preventive Controls such as Source Code Analyzer. Source: OWASP 45
Network Firewalls Do Not Work For HTTP Firewall Web Client Web Server Application Application Database Server HTTP Traffic Port 80 Source: OWASP 46
TYPICAL CLOUD BASED ENVIRONMENT
SUMMARY : What constitutes an effective Application Security Strategy for PCI-DSS compliance 1. Adoption of Risk-based, holistic & Defence-in-Depth approach. 2. Effective implementation of key policies, procedures and processes (e.g. Change Management, Patch Management etc. ) 3. Use of Frameworks and Industry Standards and best practices like CoBIT 4.1, ISO 27001: 2005 and so on to ensure effective implementation of general IT Controls and IT Assurance framework. 4. Deploy Industry best practices for Secure Code development, Testing, Code Review e.g. OWASP XML Web Security Services Forum (XWSS) Common Weakness enumeration (CWE) 2011 / SAN Top 25 5. Deploy tools (as Preventive & Detective controls) like: Source Code Analyzers Web Application Firewall Web Application Scanner 6. Conduct periodic Pen Test 7. On-going training and awareness on Application Security 48
Questions 49
CONTACT: Contact: ASHIT DALAL, PCI-DSS QSA, CRISC, CGEIT, CISA,CISM, CPEA, CSSA Six Sigma Black Belt Sr. Manager & Managing Consultant K3 DES LLC, NJ (USA) T.NO: 609-575-4645 (USA) +91-98191-18590 (India) Email: ashit.dalal@k3des.com 50