dotdefender Web Application Security PCI Compliance and You Co-authored with STI Group 1
What is PCI? PCI refers to the Payment Card Industry Data Security Standard (PCI DSS). This standard was originally developed from elements of the information security standards from 5 individual card brands: Visa Cardholder Information Security Program (CISP) MasterCard Site Data Protection Program (SDP) American Express Data Security Operating Policy (DSOP) Discover Information and Compliance (DISC) Japan Credit Bureau (JCB) Data Security Program Due to the consistency of the underlying intention of these standards, the card brands aligned their individual policies in December 2004 with the formation of the PCI Standards Council and the release of the Payment Card Industry Data Security Standard (PCI DSS). Since its inception, the PCI standard has been revised and updated. The current revision is PCI DSS 1.2.1, which consists of the 1.2 standard released in October 2008, with clarifications announced in August 2009. The PCI standard defines a specific set of requirements intended to provide appropriate security for credit card information. These requirements include a wide range of technical and procedural measures including security policies, firewalls, intrusion detection systems, network segmentation, encryption technologies, and a variety of other security controls. While some of the requirements are specific in nature, several of the requirements are intentionally non-specific in order to allow for flexibility in satisfying the intent of the requirement(s). Why is it important? The PCI DSS is applicable to merchants and service providers that deal with credit card information in the course of conducting business. It is especially relevant to online merchants that store credit card primary account numbers (PANs). Merchants are grouped into four levels by transaction volume: Level 1: Greater than 6 million annual transactions Level 2: Greater than 1 million annual transactions Level 3: Greater than 20 thousand annual transactions Level 4: Fewer than 20 thousand annual transactions 2
Service Providers are grouped into two levels by storage, processing, and/or transmission volume: Level 1: Greater than 300 thousand annual transactions Level 2: Less than 300 thousand annual transactions While the applicable requirements are consistent regardless of the level of the merchant or service provider, different levels are mandated to undergo different processes to achieve PCI compliance. For example, Level 1 merchants are required to undergo an onsite assessment by a certified QSA (Qualified Security Assessor), while Level 2 merchants can currently provide a self-assessment through the submission of a Self Assessment Questionnaire (SAQ). These guidelines are further complicated by the fact that the card brands, or the bank that accepts credit card payments on behalf of a merchant (often referred to as the Acquiring Bank ), can mandate an onsite assessment for compliance at their discretion as a condition of doing business with the merchant or service provider. Dom Genzano, Senior Partner at STIGroup, an information security consulting firm which specializes in helping companies achieve PCI compliance, adds: PCI DSS compliance for many organizations begins with the challenge of accurately classifying themselves as a merchant or service provider, and then correctly identifying the merchant or service provider level that applies to their business. While the PCI Security Standards Council manages the PCI Data Security Standard and the associated requirements, the compliance process is managed by the individual card brands and the acquiring banks. The card brands may, at their discretion, fine an acquiring bank between $5,000 and $10,000 per month for sponsoring merchants or service providers that are not PCI compliant; the acquiring bank typically passes these fines downstream to the non-compliant entities. In the event that a noncompliant organization is compromised, fines from the card brands can be delivered in a variety of forms, from $25 per compromised account to a single enumerated fine of $500,000 or more, depending on the card brand(s) involved. In addition to the fines levied by the card brands, non-compliant organizations risk penalties for violation of state and federal statutes, as well as irreparable damage to their corporate reputation and customer confidence. 3
The Core Elements of the PCI Data Security Standard Goals PCI DSS Requirements Build and Maintain a Secure Network 1. Install and maintain a firewall configuration to protect cardholder data Protect Cardholder Data 3. Protect stored cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program 5. Use and regularly update anti-virus software or programs 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 Maintain an Information Security Policy 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes 12. Maintain a policy that addresses information security for employees and contractors Best practice is the key Web application security is an essential component to PCI compliance. Richard Shinnick, Senior Partner at STIGroup, states: It is no secret that e-commerce, as a percentage of overall sales, is increasing. Companies are being forced to have a Web presence capable of accepting credit card payments to be competitive. The PCI standards applicable to Web application security, specifically those in requirements 6.5 and 6.6 of the standard, are becoming increasingly significant. 4
Web application security - Section 6.5 and 6.6 Requirements 6.5 and 6.6 of the PCI DSS provide specific requirements for the security controls that deal with the development and vulnerability management of Web applications: 6.5 Develop all Web applications (internal and external, and including Web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following: 6.5.1 Cross-site scripting (XSS) 6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws. 6.5.3 Malicious file execution 6.5.4 Insecure direct object references 6.5.5 Cross-site request forgery (CSRF) 6.5.6 Information leakage and improper error handling 6.5.7 Broken authentication and session management 6.5.8 Insecure cryptographic storage 6.5.10 Failure to restrict URL access 6.6 For public-facing Web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing Web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes Installing a Web-application firewall in front of public-facing Web applications 5
As shown, requirement 6.6 mandates one of two options for the protection of public-facing Web applications: Review of custom application code for vulnerabilities. This code review can be conducted by a qualified third party organization or by qualified internal resources that were not involved in writing the code. Installation, and appropriate configuration and management, of a Web Application Firewall (WAF) to protect Internet-accessible Web applications. In April 2008, the PCI Standards Council released an Information Supplement to clarify the intent of the options presented for compliance with requirement 6.6: The intent of Requirement 6.6 is to ensure Web applications exposed to the public Internet are protected against the most common types of malicious input. There is a great deal of public information available regarding Web application vulnerabilities. The minimum vulnerabilities to consider are described in Requirement 6.5. Proper implementation of both options would provide the best multi-layered defense. PCI SSC recognizes that the cost and operational complexity of deploying both options may not be feasible. Further, one or the other option may not be possible in some situations (no access to source code, for example). However, it should be possible to apply at least one of the alternatives described in this paper, and proper implementation can meet the intent of the requirement. Dom Genzano from STIGroup comments further on the recommended approach to satisfy the intent of requirement 6.6: While compliance can be achieved with either approach, it s been our experience that the institution of a code review process in conjunction with a Web Application Firewall implementation is the ideal approach to meet the intent of requirement 6.6. Code review prior to the production release of a Web application is minimum due diligence as a part of a typical quality assurance process, and the insertion of vulnerability checks into this process is appropriate. However, a code review process can never be counted on to fully mitigate the risk of Web application vulnerabilities, especially in more dynamic environments. A WAF is an essential security layer to supplement the code review process, and the Applicure dotdefender is a best-of-breed product that effectively provides this security layer. The traditional perimeter security systems mandated by the PCI standard do not provide adequate protection to Web applications as they are not designed for that purpose: Perimeter firewalls must allow inbound access from the Internet to Web services in order for publicfacing Web applications to be available. These firewalls generally do not provide the level of packet inspection required to protect Web applications from exploit attempts. While Intrusion Detection and Prevention systems do provide for some recognition of Web-based attacks, they are not specifically designed for this purpose, and they do not provide comprehensive protection against exploit attempts for the range of Web application vulnerabilities listed in PCI requirement 6.5. 6
Because traditional perimeter security technologies do not provide adequate protection against the exploit of Web application vulnerabilities, and hackers have continued to succeed in compromising credit card data through exploit of Web applications, the PCI standard has evolved to require measures specifically designed to mitigate this threat. Option one, code review: As per the Information Supplement provided by the PCI Standards Council for requirement 6.6, the code review consists of one or more of the following 4 alternatives : Manual review of application source code This alternative involves a manual inspection of source code for the presence of Web application vulnerabilities described in PCI requirement 6.5, as well as other common relevant vulnerabilities. This code review can be conducted by either a qualified 3 rd party, or by qualified internal resources not involved in writing the code. This method should be employed as a part of compliance with PCI requirement 6.6 as code review is a necessary part of a reasonable quality assurance process. While a representative sampling strategy can be used to reduce the scope of the effort (and expense if a third party is engaged for this process), this method is not recommended as the sole means of satisfying requirement 6.6, as human errors and inconsistencies can never be completely eliminated from a manual review process. Yaacov Sherban, Applicure CEO, says: A code review can be accurate for the moment it is actually done, but as soon as anything changes with the application, it will be outdated and the potential for human error will be re-introduced. We believe that when businesses look into the details of what code reviews entail, many will choose the WAF route! Proper use of automated application source code analyzer (scanning) tools This alternative consists of running an automated code scanning tool to inspect the code for issues with structure, syntax, etc. that indicate the presence of Web application vulnerabilities. This method is seldom reliable on its own due to the variable nature of application coding, especially with the more proprietary custom applications. This method could be reasonably employed to supplement a manual code review, but is not recommended as the primary means of satisfying PCI requirement 6.6. Manual Web application security assessment A manual Web application security assessment involves security-specific testing by a qualified third party or internal resource to check for the presence of Web application vulnerabilities and assess the risk of exploit. While this method is an essential part of the security testing for the release of a new Web application, or the production deployment of a new version containing significant changes, it is often cost and/or resource prohibitive to employ as a part of the process for regular Web application changes and updates. This alternative also does not offer a consistent enough delivery structure to be reliable as the sole means of satisfying PCI requirement 6.6. It is also worth noting that the information 7
produced through this method often overlaps with the output from a Web application penetration test, which is mandated by PCI requirement 11.3.2 to be performed annually or after any significant change to Web application(s). Proper use of automated Web application security vulnerability assessment (scanning) tools The consistent use of an automated, and regularly updated, Web application vulnerability scanner is recommended as a part of compliance with PCI requirement 6.6 as it is an essential part of a reasonable information security program. By leveraging such a tool in conjunction with a code review process, consistency can be gained in the security testing process to mitigate some of the potential for human error, and reasonably reliable testing for the presence of known Web application vulnerabilities can be performed. However, automated scanning tools cannot be reasonably relied upon as the sole means of satisfying requirement 6.6. As Yaacov Sherban of Applicure states, Web application vulnerability scans can only detect vulnerabilities that are known at the time of the scan, but new vulnerabilities are being found on a daily basis. Also, slight variations in code structure can cause the results of a particular vulnerability test from an automated scanner to be unreliable. It is essential that an application-level firewall be introduced to mitigate this risk. Option two, the Web Application Firewall: The PCI Standards Council defines a Web Application Firewall as a security policy enforcement point positioned between a Web application and the client end point. This functionality can be implemented in software or hardware, running in an appliance device or in a typical server running a common operating system. It may be a stand-alone device or integrated into other network components. As the statement from the PCI Standards Council implies, a WAF can take many form factors, including a dedicated hardware appliance, a component feature built into a firewall or load-balancer, or a software agent installed on the Web server(s). Each form factor represents a different scenario of advantages and disadvantages for implementation and Web site protection. For example, while a dedicated hardware appliance can have an initial advantage with scalability, the implementation typically involves changes to the network architecture. Developers of WAF products strive to maximize the advantages of the form factor(s) of their product while minimizing the inherent disadvantages. A valid Web Application Firewall is designed to inspect the contents of IP packets for any data that is processed by the Web application in order to identify the presence of malicious input or other violations of security policy. This distinction is important because many solutions claim to contain WAF technology through the incorporation of functions such as packet or content filtering, SSL inspection, etc., but do not satisfy the intent of PCI requirement 6.6. An effective Web Application Firewall must be able to: Inspect all application input and respond based on rules or policy. 8
Prevent data leakage by inspecting output based on rules or policy. Support both positive (whitelist) and negative (blacklist) security models. Inspect both Web page content, such as Hyper Text Markup Language (HTML), Dynamic HTML (DHTML) and Cascading Style Sheets (CSS) as well as the underlying protocols that deliver content, such as Hyper Text Transport Protocol (HTTP) and Hyper Text Transport Protocol over SSL (HTTPS). Inspect Web services messages, if Web services are exposed to the public Internet. Typically this would include Simple Object Access Protocol (SOAP) and extensible Markup Language (XML), both document- and RPC-oriented models, in addition to HTTP 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. Not only will the installation of a WAF satisfy PCI requirement 6.6, but it will also actively provide ongoing security for Web applications, effectively closing the gaps inherent to code review and security scanning processes. Dom Genzano from STIGroup comments further: Web application exploits have been an increasingly prevalent attack vector, and we expect this trend to continue. A Web Application Firewall is an indispensable component of an effective information security program for a business that utilizes Web applications. While a WAF provides an effective and efficient means of protecting Web applications from compromise, it is recommended that it be employed as a part of a layered approach to security. The ideal layered approach would include other processes that target the intent of PCI requirement 6.6 such as code review and automated Web application vulnerability scanning, as well as supplemental technologies that target other PCI requirements, such as intrusion detection/prevention systems and event log management solutions. The layered approach to security Multiple layers of security, consisting of supplemental and overlapping technologies and processes, are essential to an organization achieving a sound information security posture. The advantages of a layered approach include: Overlapping security controls provide a safety net for the inherent gaps in functionality present in various security systems, and also provide added protection against human error (especially when separation of administrative responsibilities is properly employed). Supplemental security controls provide further protection from security issues that fall outside of the capabilities of a given security technology, and also provide additional analysis and forensic information that may be critical to the identification, diagnosis, and response in the case of a 9
security incident. As pointed out by Dom Genzano from STIGroup: While the PCI Data Security Standard is not perfect in this regard, it is clearly designed with the intent of overlapping and supplemental controls to achieve a more effective overall security posture. For example, with regard to Web applications, the security controls introduced through the execution of code reviews and installation of a WAF in targeting PCI requirement 6.6 are increased in effectiveness when coordinated with additional controls mandated by the PCI standard: Event log review (PCI requirement 10.6) Quarterly vulnerability scanning (PCI requirement 11.2) Annual penetration testing (PCI requirement 11.3) Intrusion detection systems (PCI requirement 11.4) File Integrity Monitoring (PCI requirement 11.5) Daily security operational procedures (PCI requirement 12.2) Incident response procedures (PCI requirement 12.9) It is important to consider the selection and implementation of security systems and processes in the context of the layered security approach. By actively selecting and configuring security technologies with due consideration to overlap and supplementation of capabilities, a much stronger security posture can be achieved and operational efficiencies can be maximized. Hardware or software? There are a wide variety of both hardware and software Web Application Firewalls on the market. While each specific technology has unique aspects to it, some generalizations can be made about each approach to identify key advantages and disadvantages: Hardware appliances tend to provide for more initial scalability, while also having a higher initial cost of ownership and ongoing maintenance costs. Hardware appliances tend to make use of learning algorithms and statistical analysis for the baselining and monitoring functions. While this can introduce flexibility to the process, it can have an adverse impact to system performance and resource requirements. Hardware appliances tend to require a change in network architecture for implementation, and can sometimes represent a performance bottleneck or additional complexity in the network design. Some vendors mitigate these potential issues by implementing Web application firewall capabilities in multi-function appliances that provide other critical functions such as stateful-inspection 10
firewalling or server load-balancing. Software based solutions tend to have a lower entry cost, especially for installations consisting of 1 or 2 Web servers. The approach can become expensive for large amounts of Web servers based on the structure of the licensing costs. Software based solutions tend to have more preconfigured out-of-the-box functionality with regard to security, as their proximity to the Web application services allow for more successful use of pre-determined rules. Software based solutions provide a distributed approach to Web application firewalling, that typically represents a more attractive approach for collocated Web applications or Web applications that span multiple locations. Applicure has chosen the software form-factor for its Web application firewall solution. As explained by CEO Yaacov Sherban, The hardware/software discussion hinges on the type of company you are. Hardware is always more expensive, and we estimate that around 80% of the WAF market isn t being served by hardware, as it s simply too complex and costly. Bear in mind also that the learning algorithms will require quite a long time to understand the environment and begin generating rules. Software, on the other hand, is a far more viable option for small and medium size companies, but also can be a great fit for larger enterprises, especially those with dynamic Web applications. Software also makes compliance easier once it s installed correctly and the paperwork is done, that box is checked. Applicure developed the dotdefender WAF specifically with the intent of maximizing the advantages, and minimizing the disadvantages, inherent to software-based Web Application Firewalls. Some key aspects of the technology are: Effective out-of-the-box security functionality that provides an effective balance between providing a high level of security and minimizing false positives. Extremely light footprint that provides for flexible installation options and minimizes impact on system resources. Flexible and secure communications and management capabilities which facilitate distributed installations with little-to-no network design changes required. Advance integration and automation options using open API. Progressive licensing cost structure which allows for cost-effective scalability. dotdefender is a particularly attractive solution for many businesses because its deployment requirements are so simple. It is cross-platform (IIS and Apache are supported on Windows and Linux) and is extremely straightforward to implement and maintain. Its total cost of ownership is extremely low, especially as compared to hardware-based solutions with similar capabilities. 11
We ve effectively leveraged Applicure dotdefender as a Web Application Firewall solution for a variety of businesses. states Dom Genzano, Senior Partner at STIGroup, The product allows us to secure a customer s Web applications very quickly - typically in less than 24 hours - and the distributed nature of the solution makes it an ideal fit for clients that request outsourced management of the technology, which our firm provides. Applicure s PCI-compliant solution dotdefender is a software-based Web Application Firewall that delivers excellent ROI through reasonable cost, simple deployment, efficient management, and effective Web security. dotdefender prevents abuse of Web application functionality by protecting against threats including: Web Application Attacks: including SQL injection, path traversal, cross site scripting, header tampering, and probes. Session Attacks including session hijacking, cookie tampering, denial of service, and encoding violation. Known Attack Sources including known worms, compromised servers, spammer bots, known spammers and bad user agents. Installed as a Web server plug-in, dotdefender provides tight website security quickly and efficiently. It has no influence on traffic or network architecture, utilizes minimal Web server resources, and handles encryption transparently to enable tight security with negligible performance degradation. dotdefender comes with a predefined set of internet security rules for out of the box best practice website protection. Automatic live updates ensure that your website security is ready to counter the latest malicious attacks. Simple customization and effortless maintenance ensures versatile protection that works for businesses of any size and complexity. While dotdefender does an effective job at minimizing false positives with the predefined rules, it includes intricate base-lining and customization capabilities, and provides an efficient methodology for identifying and dealing with false positives that minimizes their effect on the end-user experience. The Central Management console produces customizable periodic and on-demand reports on application attacks, sources of attack, and which application vulnerabilities they target. Life after WAFs The implementation of a WAF is a practical and appropriate step towards achieving PCI compliance and is also consistent with industry best-practices in information security. Dom Genzano from STIGroup adds: The implementation of a Web Application Firewall solution has become a consistent part of the information security services that we provide to our customers. Whether this technology is positioned as the outcome of a security assessment, a part of a regulatory compliance strategy, or as a response component to a forensics engagement, we ve often found that the introduction of a WAF to a customer environment is an effective and efficient means of providing an appropriate level of Web application security that is too often lacking in many organizations. 12
While a Web Application Firewall cannot be fully effective unless implemented as a part of a comprehensive security strategy, it is an essential component to Web application security as it provides a level of protection not currently offered through other technologies. About STIGroup Secure Technology Integration Group, Ltd. (STIGroup) is an Information Security Consulting firm that provides a full suite of Information Security services. STIGroup designs, implements, and maintains the systems and procedures that permit your business to utilize technology productively while maintaining the confidentiality, integrity, and availability of your mission-critical information. In addition to security consulting services, and design and implementation services for security technologies like AppliCure dotdefender, STIGroup provides managed services to monitor and maintain technology implementations to ease the burden on your internal staff. STIGroup has a PCI Compliance Consulting program specifically designed to help businesses address the challenge that PCI Compliance represents. Our experienced consultants will work with your team to cost-effectively take you through the PCI Compliance process. Our services include: Policy Development and Gap Analysis Penetration Testing Technology Implementations Managed Services STIGroup has a significant track record of success with financial services, merchants, and providers, in the execution of the strategic and tactical initiatives required for PCI Compliance - as well as any overlapping or supplemental regulatory requirements that are applicable to your business, such as FDIC, GLBA, and HIPAA. Our services, project methodology, and best-of-breed vendor partnerships allow us to work with your organization to achieve and maintain regulatory compliance in a cost-efficient manner, while effectively aligning your regulatory compliance strategy with the goals of your business. For more information about STIGroup s PCI compliance consulting programs, or other STIGroup services, contact us at 888-881-6661 extension 311 or via email at sales@stigroup.net. Visit us on the Web at www.stigroup.net/pci. 13
About Applicure Applicure Technologies Ltd. (TASE: APCR) develops the leading multi-platform Web application security software products to protect websites and Web applications from external and internal attacks. Built upon years of research into hacker behavior, Applicure solutions feature a comprehensive knowledge base to identify attacks accurately, and stop them before they reach their target. Applicure s dotdefender enables companies to address challenging PCI DSS requirements in a straightforward and cost-effective manner. For more information contact us at 1-800-584-4888 or via email at sales@applicure.com. Visit us on the Web at http://www.applicure.com/ to download a free 30 day trial of dotdefender. 14