Meeting the PCI Application Security Requirements

AN OUNCE SECURITY TOPICS WHITE PAPER Meeting the PCI Application Security Requirements: BUILDING COMPLIANCE IN Meeting the PCI Application Security Requirements 1 Meeting the new PCI Application Security Requirements: Building Compliance In “The security of customer payment data is not just a payment brand issue but is the responsibility of all businesses that participate in the payment process. All merchants and service providers that store, process and transmit payment card data are required by the payment brands to comply with the PCI Data Security Standard – their customers expect it and their reputations depend on it.”1 PCI Security Standards Council Since 2005, over 215 million data records have been exposed as a result of security breaches. Privacy Rights Clearinghouse2 Since 2005, over 215 million data records have been exposed as the result of security breaches.2 Uproar in the press, worldwide legislative bodies, and among consumers has spurred industry groups to work toward regulations and best practices concerning the security of private data. Leading the way has been the Payment Cards Industry (PCI) Security Standards Council, who has issued the PCI Data Security Standard (PCI DSS) to establish specific requirements for payment account security. Originally established by the major credit card companies, the Council provides a mechanism for the development of security standards, guidance for implementation of the standards, and a compliance schedule. With the publication of the PCI DSS, merchants processing card data across the global marketplace now have a much clearer road map for establishing the proper controls and demonstrating the exercise of due care in the handling of their customers’ credit card data. Through the PCI DSS, vendors are required to: Build and Maintain a Secure Network Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data Requirement 3: Protect stored cardholder data Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program Requirement 5: Use and regularly update anti-virus software Requirement 6: Develop and maintain secure systems and applications Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need-to-know Requirement 8: Assign a unique ID to each person with computer access Requirement 9: Restrict physical access to cardholder data Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 11: Regularly test security systems and processes Maintain an Information Security Policy Requirement 12: Maintain a policy that addresses information security3 Each of these broad-based mandates has a specific set of requirements associated with them, and guidance is provided by the Security Standards Council to help organizations implement and prepare their compliance. Compliance rates low Recent surveys of merchants has shown clearly that compliance with PCI requirements is lagging, in spite of some significant investment. Visa USA. the only card brand to release statistics on compliance thus far, has stated that compliance rates are only 36% among its level-one merchants (those processing more than 6 million card transactions per year) and 15% among its level-two merchants (those processing between 1 million and 6 million transactions per year). 4 However, most companies interviewed by Forrester Research expect to reach compliance by mid 2008.5 Meeting the PCI Application Security Requirements 2 The greatest challenges to reaching compliance cited by Forrester include: Building security in: making security an integral part of daily processes throughout the organization, in policy and process Auditing and reporting: proving compliance can be as difficult as achieving it Ensuring partner security: achieving the insight into the security of those with whom data is shared.6 In custom application development in particular, organizations struggle with integrating security throughout each phase of the development lifecycle, and producing audit reports that demonstrate the status of PCI compliance in both in-house and outsourced systems. Addressing these challenges will require a combination of the right process, the right skills, and the right tools. It is vital that organizations subject to the PCI requirements start on this initiative immediately. Says John Pescatore of Gartner, “The rapid rise of targeted threats makes increased application security something enterprises should focus on today.”7 PCI’s Global Impact The pressure on organizations to comply with PCI standards is being felt worldwide, as global markets and transactions are predominant, and the impact of data security breaches transcends national borders. The card brands are global entities and as such are executing a worldwide rollout of the PCI compliance end enforcement schemes. American Express, for example, anticipates completing its worldwide rollout in 2008, according to Gartner.8 Only 39% of Europeans are currently addressing PCI compliance vs. 63% in the United States Jericho Forum9 That pressure is being felt among executives worldwide. A recent survey of European security professionals by Qualys and the Jericho Forum found that 74% of European senior security executives see the impact of payment card loss on brand reputation as their biggest concern. The same survey showed that Europeans need to catch up on with United States companies in the area of PCI compliance. Only 39% of Europeans are currently addressing PCI compliance versus 63% in the United States.9 While enforcement activities have been lagging outside of North American, the card companies will clearly be turning their attention to global markets during 2008, and legislation, country by country, will likely follow the pattern set in the United States and Canada, making disclosure mandatory when breaches occur. Security breach disclosure proposals being considered by the European community include a requirement that regulators are notified when a security breach takes place.10 PCI Compliance: It’s not just for credit card companies anymore The PCI DSS is demonstrably becoming a de facto standard of due care for any organization responsible for the privacy and integrity of data. As a result, state and federal lawmakers are incorporating similar standards into the development of data privacy legislation. The first step for many states has been requiring disclosure in the event of a breach, either upon access or potential exposure of the data, or in the event of a material exposure. Figure 1 below shows the preponderance of states that have some sort of regulation regarding breach disclosure. Meeting the PCI Application Security Requirements 3 Figure 1: State by State Breach Disclosure Laws Key: A = Access/Potential Exposure Primary source: pirg.org R = Risk of Material Exposure/Compromise Also on the rise is legislation addressing standards for data security modeled on the PCI and OWASP standards, as well as associated penalties for non-compliance, and rewards for compliance. One example is the state of Texas, which has a bill under consideration which would provide protection to organizations that demonstrate compliance with PCI DSS, and institute liability for card re-issuing fees to those who are not compliant.11 Organizations outside of financial services and retail are feeling increasing pressure from legislators, stockholders, press, and customers to take concrete steps to protect critical data from misuse or corruption. The coming years will likely continue the move towards a universally accepted standard of due care in data privacy. Most companies have a fairly comprehensive security deployment in place, making use of firewalls, VPN, access control and encryption to safeguard their valuable assets. PCI DSS, however, takes a more holistic look at security, understanding that it is only through a defense-in-depth model of security that data assets can be most efficiently secured. With this view in mind, PCI is the first regulation to spell out the need for security rigor around the applications themselves. Applications: A Potential Source of Security The increased focus on application security in the latest revisions of the PCI DSS can be traced directly to many of the recent high profile breaches, where insecure applications have proved to be the point of access for hackers, and the source of data loss. An InformationWeek article emphasizes the threat due to software problems, stating that, “the steady stream of disclosures that customer information is being lost or stolen from retailers has caused security experts to focus on two areas: poor security practices by the retailers themselves and weaknesses in the software used to process credit-card payments.”12 The article reports that Polo Ralph Lauren Corp. blamed a software glitch for a security breach that prompted HSBC North America to notify holders of its General Motorsbranded MasterCard that their personal information may have been stolen.13 BJ’s Wholesale Club, in another high-profile incident, filed suit against IBM, blaming faulty software provided by the Meeting the PCI Application Security Requirements 4 company for a breach that exposed 40 million credit card numbers and expenses to BJ’s in excess of 13 million dollars.14 These incidents, among others, drew a direct line from the PCI Council right to the expanded application security requirements contained in Version 1.1 of the Data Security Standard. Focus on Application Security: Requirement 6 Application security represents one of the areas most challenging to organizations subject to PCI regulations. The most recent version of the PCI DSS, published in September 2006, strongly reflects the growing industry understanding about the impact of insecure applications on data privacy. The most significant addition to the Standard is the inclusion of a new mandate for the security of custom applications codified in Requirement 6: Develop and maintain secure systems and applications. Specifically, Requirement 6.6 states that all custom application code must be reviewed for common vulnerabilities by an organization that specializes in application security or there must be a Web application firewall installed in front of Web-facing applications. This requirement will be considered a "best practice" until June 30, 2008, and then it becomes a requirement.15 This requirement, together with the other detailed requirements of the section, make application security a cornerstone of the PCI compliance effort and the drive to protect cardholder data. It is a clear recognition that true data security must begin at the source. Compliance Starts at the Source These new requirements clearly recognize that data security starts with software security. It is in source code that encryption is enforced, the security of network communications is established, access control is set. Or not. Therefore, it is in the source code that the drive for compliance with the PCI DSS, and the effort to secure private cardholder data, must begin. While the PCI DSS includes web application scanning and web firewalls as part of the potential solution set to address these issues, it is clear that source code scanning tools represent the most For companies efficient, cost effective, and comprehensive solution to identify and address software developing their own vulnerabilities that affect data privacy. As Gartner analysts John Pescatore and Avivah Litan stated in a recent report, “For companies developing their own software, the most software, the most effective approach is to integrate source code vulnerability scanners into the application effective approach is to development, integration and test process.”16 integrate source code vulnerability scanners into the application development, integration, and test process Gartner Research16 Building PCI Compliance In The increasingly diligent attention on the security of source code springs from the fact that it is the central place where vulnerabilities to credit card data get introduced. It can also the least expensive place to address them, when source code analysis is performed at the earliest point in the software development lifecycle. For organizations charged with PCI compliance, it makes both fiscal and governance sense to introduce source code scanning into the development lifecycle for custom and outsourced code. Leaving it solely to the responsibility of an outside organization reduces the financial benefit of early discovery of vulnerabilities, and increases the likelihood of project delay and risk. The leading source code analysis solutions use an extensive vulnerability knowledgebase powered by a scanning engine able to scan large amounts of source code efficiently. The knowledgebase should include not only the common coding errors that create opportunities for hackers, but also the identification of design and policy errors that pose the greatest danger to private data. To truly address PCI compliance issues, as well as the total software security risk to credit card information, the source code scanner must look for coding errors as well as policy violations and design flaws. The Ounce Labs toolset, for example, covers both types of issues and their analysis includes: Meeting the PCI Application Security Requirements 5 Coding vulnerabilities Buffer overflows Format string vulnerabilities Race conditions Resource leaks Input/Output validation and encoding errors SQL injection Cross-site scripting OS injection Design flaws and policy violations Cryptography Network communication vulnerabilities Application configuration vulnerabilities Access control Database and file system use Dynamic code Access control and authentication errors Error handling and logging vulnerabilities Insecure error handling Insecure or inadequate logging Native code loading Data storage vulnerability Insecure Components Malicious Code Unsafe native methods Unsupported methods Custom cookies/ hidden fields Where Source Code Meets PCI Compliance As always, the devil is in the details. There are multiple regulations within the PCI DSS on which source code security has an impact. It is vital that organizations understand the intersection of source code and each application regulation to ensure that the compliance review is comprehensive. This section provides a review of the applicable application security regulations for PCI, and in what ways source code scanning should support compliance. Requirement 3: Protect stored cardholder data There is no more critical requirement than the need to protect cardholder data in its stored state. Applications play a critical role in this task, particularly through the proper implementation of appropriate access control and cryptography. Compliance with this requirement cannot be assured unless the applications processing and storing the data have been comprehensively reviewed. Meeting the PCI Application Security Requirements 6 PCI Requirement 3.2 Do not store sensitive authentication data subsequent to authorization 3.3 Mask Primary Account Number (PAN) when displayed 3.4 Render PAN, at minimum, unreadable anywhere it is stored. Use appropriate types of encryption. Source Code Scanning Compliance Action Identify potentially vulnerable or noncompliant cardholder data storage practices. Check for unsafe cardholder data storage practices. Check for PAN output and masking. Identify all points of PAN storage, and verify cryptography and cryptographic strength that are in use Requirement 6: Develop and maintain secure systems and applications This requirement is the core regulation addressing the need to validate the security of sensitive applications. It directly addresses the foundation of secure applications: the introduction of security processes and review throughout the software development lifecycle. Planning, design, development, and deployment: all the stages of the lifecycle must make security considerations a top priority to make compliance possible and demonstrable. PCI Requirement 6.2 Establish a process to identify newly discovered security vulnerabilities. 6.3 Develop software applications based on industry best practices and include information security throughout the software development life cycle. 6.4.1 Documentation of impact 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. 6.6 Ensure that all web-facing applications are protected against known attacks(.) Source Code Scanning Compliance Action Provide the technology support to enable consistent. Measurable assessment of the security state of source code, throughout the development phase Comprehensive security knowledgebase Precise metrics Roles-based interfaces and reporting to deliver the required PCI compliance information to all stakeholders In-depth reporting for audit documentation and traceability. Produce PCI-specific reports to deliver management and technical data required by the PCI Standard. Specific reporting on source code impacts on data loss Reporting on OWASP Top Ten compliance Scan history to demonstrate ongoing compliance efforts Reporting in both summary and detail to support specific vulnerability remediation, managerial decisionmaking, and compliance reporting requirements Meeting the PCI Application Security Requirements 7 Proving Compliance Implicit and explicit in all of the above requirements is the need to document compliance activities. Documentation is required not only to track results, but also to prove that a process is in place, demonstrating due care in the effort to reach compliance and protect data. The adage “you can’t manage what you can’t measure” is particularly true in the arena of application security. The cornerstone of any implementation of source code scanning, therefore, must be the ability to produce specific and detailed reports of the results of scans and any subsequent remediation activities. Each constituent in the lifecycle compliance process, from managers to developers, QA, and compliance officers, must be able to derive the data they need to complete their role in the process. Code Scanning: The Foundation of Compliance Source code scanning is the foundation of a range of potential options available to organizations to monitor the security and compliance state of their applications. Gartner’s recognizes source code scanning as the most effective approach, as cited above. But the research firm goes on to state that where it “is not possible, enterprises that have sufficient security staff and expertise can use Web application scanning products…during the final quality assurance testing of software.”17 There are several advantages to source code scanning, however, that make it the first best choice of organizations concerned with meeting the standard of due care using the most efficient and costeffective method possible. The advantages of source code scanning over penetration testing for custom applications include: Lower remediation costs: penetration testing cannot be deployed until an application is complete. Source code scanning can be used at the earliest point in the Build stage of the development lifecycle, reducing the cost of correcting the vulnerabilities dramatically. Studies have shown that fixing a vulnerability after development is complete can cost 100x what it would have cost to fix it in development. Comprehensive coverage of security risks: penetration testing covers a smaller subset of software risks, focusing on coding errors without the capability to identify the more dangerous risks stemming from design errors and policy violations. These might include such threats to data privacy as the lack of encryption, the use of hardcoded passwords, the improper use of email or the insecure storage of private data. Sophisticated source code scanners can provide coverage across this wider range of vulnerability, to get at the true source of threats to data privacy and integrity. Line-by-line identification of vulnerabilities: knowledge that a vulnerability exists is not enough. Developers need to know where in the code to go to address the vulnerability, and only source code scanning can provide that level of detail and insight. Analysis of entire software infrastructure: penetration testing is designed to work exclusively on web applications. Often, the critical threat to data comes from a middleware or back-end application, beyond the reach of the web application scanner. Only an analysis of the source code of the interrelated systems can provide a truly complete picture of the risks to critical data. PCI DSS also allows the use of Web application firewalls to be deployed in front of applications that have not been tested. These products can be effective in blocking many attacks against typical Webbased applications, but they require significant tuning and administrative support. Gartner recommends that “enterprises use Web application firewalls only as a last resort, or, when budget permits, as an added security precaution.”18 While both penetration testing and web application firewalls can be useful tools just prior to or after deployment, it is source code scanning that Meeting the PCI Application Security Requirements 8 represents the most effective and comprehensive foundation technology for identifying and eliminating the vulnerabilities that threaten data privacy and regulatory compliance. PCI Compliance and Ounce Ounce Labs has been one of the leading source code analysis vendors to provide PCI-specific capabilities within its tool. The product uses a PCI-specific “lens” to view the source code scanning results as it relates to specific PCI regulations, including auditing compliance with the OWASP Top Ten. Through the company’s PCI “SmartAudit” report, customers are able to automate the assessment of the vulnerability state of their critical applications. Only the Ounce Labs solution has been designed from the ground up to provide your executives, analysts, developers and auditors with the answers they need to manage the risk from vulnerable software: Quickly identify the most serious security risks: Ounce’s unique analysis capabilities identify the most critical coding errors and design flaws Maximize the effectiveness of your security stakeholders: The fastest time-to-results streamlines security efforts throughout the SDLC, for all stakeholders Manage risk across your enterprise portfolio: Centralized dashboards and policy management capabilities allow at-a-glance information about your software risk, enterprise-wide. With a solution such as Ounce, organizations can take a truly systematic, measurable approach to PCI compliance by analyzing critical software for vulnerabilities throughout the development lifecycle, evaluating the work of outsourced developers, and proving the results of compliance efforts to management and regulators. For more information on PCI compliance and Ounce, read the Ounce PCI Compliance Overview at www.ouncelabs.com/PCIoverview. Meeting the PCI Application Security Requirements 9 1 2 PCI Security Standards Council, Press Release, January 18, 2007 Privacy Rights Clearinghouse, www.privacyrights.org, November 7, 2007 3 Payment Card Industry Data Security Standard version 1.1, PCI Security Standards Council, September, 2006 4 “Visa USA Pledges $20 Million in Incentives to Protect Cardholder Data,” Visa press release, December 12, 2006 5 “The Top 10 Things You Should Know About PCI Compliance”, Khalid Kark and Chris McClean, Forrester Research, March 23, 2007 6 Ibid. 7 “Answers to Common Questions about PCI Compliance”, John Pescatore and Avivah Litan, Gartner Research, December 7, 2006 8 “PCI Questions are Often Clearer than their Answers”, John Pescatore and Avivah Litan, Gartner, August 7, 2007 9 “74% of Security Executives Concerned About Impact of Payment Card Data Loss”, Jericho Forum and Qualys, press release, April 26 2007 10 “Encryption Market is Taking Off”, Tom Espiner, zdnet.co.uk, September 29, 2006 11 “Payment Card Security and IT Controls Explained”, James DeLuccia IV, pcidss.wordpress.com, blog, May 11, 2007, http://pcidss.wordpress.com/category/pci-dss/ 12 “Customer Data Losses Blamed On Merchants And Software,” Steven Marlin, InformationWeek, April 28, 2005 13 Ibid. 14 “BJ’s Settlement with FTC Bodes Ill for Others”, Shawna McAlearney, searchsecurity.com June 2005 15 ”PCI Council Formed; Revised Standard Includes App Security Requirement”, Colleen Frye, searchsoftwarequality.com, September 8, 2006 16 ”Answers to Common Questions about PCI Compliance”, John Pescatore and Avivah Litan, Gartner Research, December 7, 2006 17 Ibid. 18 Ibid. Meeting the PCI Application Security Requirements 10