Imperva s Response to Information Supplement to PCI DSS Requirement Section 6.6

Transcription

1 Imperva Technical Brief Imperva s Response to Information Supplement to PCI DSS Requirement Section 6.6 The PCI Security Standards Council s (PCI SSC) recent issuance of an Information Supplement piece to PCI DSS Requirement 6.6 clarifies the two options for meeting Section 6.6: Option 1: Application Code Review or Option 2: Application Firewall and provides additional details on what is required to meet each of these options. The Information Supplement piece to PCI DSS Requirement 6.6 can be found online at: Option 1: Application Code Review This clarification opens up the options for organizations to meet PCI DSS Requirement 6.6, by giving them the option to use either application code review or automated vulnerability scanning tools in order to identify application security issues to fix. The primary drawback to both approaches is that while the PCI board now allows more flexibility in how to find the vulnerabilities, PCI section 6.6 still specifically requires that organizations protect against these vulnerabilities. This means that organizations must have access to the source code as well as the appropriate personnel with secure development skill sets and adequate cycles for quality assurance, testing and re-deployment of the application. In most organizations, one or more of these prerequisites do not exist. Imperva agrees that code review and application scanning have an integral part in a best-practice approach to securing applications. However, each technology should be used in a context in which it can be effective. Code review and application vulnerability scanners work best as a tool used by developers in pre-production and quality assurance environments. Unfortunately, many vulnerabilities are only discovered during production run-time. Or, worse yet, a new class of vulnerability is found that obviates the effectiveness of prior code reviews, making previously scanned and certified applications running in production subject to a new threat. Examples of relatively recent new threat classes are Cross-site Request Forgery and HTTP Response Splitting. Often, the application developers and the IT department are at odds, because while scanning tools enable visibility into application vulnerabilities, they do not alleviate or help mitigate the issues. Typically, there are multiple cycles of scanning, code fixes and testing with unscheduled rush fixes that are costly and potentially disruptive. Because of this, Imperva recommends that the first step toward application security is to deploy a Web Application Firewall. Challenges Faced by Vulnerability Scanners and Application Code Review Scanning Web sites in production can disrupt Website performance. Applications, especially Web applications, change frequently, so the target of vulnerability scanning and code review is a moving target, and new vulnerabilities can be introduced at any time. In many cases the application can change before a review cycle has been completed Attacks, especially Web attacks, also change frequently. Prior to 3 years ago, no vulnerability scan or code review would have found response splitting problematic. Then a paper describing response splitting attack techniques required developers to send the same code back to review. From the Supplement: Individuals performing manual reviews or assessments must stay current with industry trends to ensure their evaluation or testing skills continue to address new vulnerabilities. This will be a hard requirement for many organizations to meet. For many applications the source code is not readily available or understood and, in some cases, cannot easily be changed by the organization using the Web application. This could be either because the application is a third-party application or because the original developers of a legacy application are no longer available to explain what they did.

2 Manual code reviews and manual assessments of scan results are only as good as the reviewer. Skill sets vary widely and can be very expensive. Manual code fixes are only as good as the developer. Skill sets vary widely and can be very expensive. Often, manual code fixing introduces new vulnerabilities. Management accountability: scanners identify vulnerabilities. If those vulnerabilities are not fixed, but still known, management is accountable. We know that it often takes months to fix vulnerabilities in the application. WAF provides a unique solution: it prevents the vulnerability from being exploited, allowing time to fix the code thus eliminating the accountability issue. SecureSphere Advantages over Scanners and Code Review Speed to Cardholder Data Security and Compliance SecureSphere WAF can be deployed to provide immediate protection SecureSphere WAF can be deployed without changing the application Vulnerability scanners and application code review both still require developers to manually fix code this takes time and isn t always possible. SecureSphere WAF s Dynamic Profiling technology automatically profiles applications and user behavior, automatically provides accurate protection for Web applications and cardholder data, and automatically adjusts as applications and user behavior change to provide continuous protection of Web applications and cardholder data, and can be used to provide valuable information to developers to improve the application under normal cycles. Cost Reduction SecureSphere WAF secures Web applications and cardholder data without incurring the time and cost to bring 3rd party consultants or maintaining a separate dedicated group to review code. After SecureSphere WAF is deployed, code review and code fixing projects can proceed at a controlled pace, reducing risk of errors and reducing the extra costs of emergency-mode development. Aid to Web Application Developers SecureSphere WAF provides critical information on usage patterns and changes in usage patterns that can GUIDE code review teams and point out problems so they can fix any underlying logical issues in the application Security Protection Only SecureSphere Can Provide SecureSphere WAF is the most effective mechanism to immediately address security issues since the security rule set can be adjusted to stop new attack types without the time required to change the application code. SecureSphere WAF can protect custom applications, 3rd party applications, and legacy applications even in cases where the organization does not control the source code (as for SAP, Oracle, PeopleSoft Web applications and portals) and where the people who understand the application are no longer accessible. Up to Date PCI Compliance Continuously and Automatically Imperva s internationally renowned security and compliance research organization, the Application Defense Center (ADC), provides and regularly updates PCI-specific assessments, policies, alerts, security signatures, and reports and automatically streams these updates to SecureSphere WAF management servers and gateways to ensure SecureSphere customers are always protected against the latest attacks. Comprehensive Compliance with the PCI DSS While Vulnerability Scanners are required for PCI DSS section 11.3 and can be used for section 6.6, SecureSphere helps organizations meet 8 of the 12 PCI DSS requirements. That s eight PCI DSS requirements that SecureSphere helps meet versus just two that vulnerability scanners can

3 help meet. Option 2: Application Firewalls The clarification provides more depth on what is required of a solution in order to meet Option 2 for Section 6.6. Imperva views this clarification as a positive step for the industry as there have been frequent misleading claims by solutions attempting to claim application security functionality where none in fact exists. The new guidance provides a step in the right direction in defining the specific functionality that Web application security comprises. An important part of the guidance stresses the need for a solution to provide specific application security functionality, saying: Increasingly, WAF technology is integrated into solutions that include other functions such as packet filtering, proxying, SSL termination, load balancing, object caching, etc. These devices are variously marketed as firewalls, application gateways, application delivery system, secure proxy, or some other description. It is important to fully understand the data-inspection capabilities of such a product to determine whether the product could satisfy the intent of Requirement 6.6. Imperva is the market leader in Web Application Firewalls. Imperva SecureSphere WAF is ICSA Certified and SAP Certified. Alternative solutions that embed WAF or WAF-like technology into their solutions as an afterthought do not focus on application security so they will not provide the accuracy, flexibility and scalability that Imperva provides with its SecureSphere WAF solution. A short consideration of the methods mentioned in the PCI clarification follows Traditional Network Firewalls ( packet filtering ) Traditional firewalls which perform packet filtering only cannot monitor and block by user, which is required for compliance. Also, without a white list security model, this type of solution cannot protect against parameter tampering, session hijacking and cookie poisoning attacks, among others. The bottom line is that network firewalls do not understand enough information about the application and its state over time to provide adequate application security functionality. 1st Generation / Legacy Web Application Firewalls ( proxying ) Reverse proxy only Web application firewalls introduce latency, because they terminate traffic and require changes to the network, DNS and the application itself. They may even break applications in the event of large traffic loads. Application Delivery Solutions with Application Security Add-ons ( products tailored for SSL termination, object caching, load balancing, compression, etc. ) Layer 7 content switches and first generation Web app firewalls share something in common: generally they both mandate deploying reverse proxies to modify and manage traffic. As a consequence, many application delivery vendors acquired Web app security technology and integrated it into their content switches. However, these joint solutions have retained all of the challenges of legacy Web app firewalls. For example, they often rely on manually defined white lists to validate Web requests. They protect session IDs by signing cookies and obfuscating URLs intrusive measures that often have unexpected consequences. Combining Web application security and delivery also introduced many new challenges. The extensive regular expressions and content parsing in Web security significantly degrades the performance of application delivery products, upwards to 50%. And lastly, most application delivery vendors do not specialize in Web security, so they do not regularly research new application threats or automatically update security policies.

4 Response to WAF Capabilities Requirements Recommended Capabilities A web application firewall should be able to: Meet all applicable PCI DSS requirements pertaining to system components in the cardholder data environment. React appropriately (defined by active policy or rules) to threats against relevant vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI DSS Requirement 6.5. Inspect web application input and respond (allow, block, and/or alert) based on active policy or rules, and log actions taken. Prevent data leakage meaning have the ability to inspect web application output and respond (allow, block, mask and/or alert) based on the active policy or rules, and log actions taken. Enforce both positive and negative security models. The positive model ( white list ) defines acceptable, permitted behavior, input, data ranges, etc., and denies everything else. The negative model ( black list ) defines what is NOT allowed; messages matching those signatures are blocked, and traffic not matching the signatures (not black listed ) is permitted. For organizations that wish to keep specific records of access to cardholder data, SecureSphere s secure configuration that provides role-based access control and system log auditing for all administrative access meets the requirements for storing cardholder data. SecureSphere also provides options for not storing card data in the system itself. Imperva SecureSphere WAF provides defenses against all of the OWASP Top Ten application vulnerabilities. For more information, read the Imperva Technical Brief: SecureSphere and the OWASP Top Ten Imperva SecureSphere inspects all Web application input (incoming Web traffic) and responds by enforcing the applicable security policy and rules to allow, block or alert on the events, and SecureSphere simultaneously logs all the actions taken. SecureSphere inspects outbound traffic to identify potential leakage of sensitive data such as cardholder data and social security numbers. In addition to reporting on where sensitive data is used in the application, SecureSphere can optionally prevent this information from leaving the organization. SecureSphere enforces both positive and negative security models. SecureSphere s positive model is built and maintained dynamically via Dynamic Profiling the industry s most accurate application security modeling technology. SecureSphere s negative security model is based on primary research from the Application Defense Center (ADC), Imperva s internationally recognized team of experts in application data security. SecureSphere also can enforce a combined model via unique Correlated Attack Validation, which allows for rules that combine information from multiple security layers and/or over time to provide the most accurate and effective Web application security capability in the industry.

5 Recommended Capabilities (continued) Inspect both web page content, such as Hypertext Markup Language (HTML), Dynamic HTML (DHTML), and Cascading Style Sheets (CSS), and the underlying protocols that deliver content, such as Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol over SSL (HTTPS). (In addition to SSL, HTTPS includes Hypertext Transport Protocol over TLS.) 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 RPCoriented models, in addition to HTTP. Inspect any protocol (proprietary or standardized) or data construct (proprietary or standardized) that is used to transmit data to or from a web application, when such protocols or data is not otherwise inspected at another point in the message flow. Note: Proprietary protocols present challenges to current application firewall products, and customized changes may be required. If an application s messages do not follow standard protocols and data constructs, it may not be reasonable to ask that an application firewall inspect that specific message flow. In these cases, implementing the code review/vulnerability assessment option of Requirement 6.6 is probably the better choice. SecureSphere WAF inspects all of the mentioned content and protocol types. SecureSphere fully parses and protects SOAP and XML, including XML RPC. Dynamic Profiling models the key elements of Web services applications in a manner similar to how SecureSphere profiles Web applications and database usage. SecureSphere has the broadest range and flexible support for inspecting all types of (proprietary or standard) HTTP traffic. SecureSphere has plug-in architecture to support non-standard variance of communication to Web applications. SecureSphere also uniquely offers the capability to fully inspect SQL activity (i.e. database activity) via an option upgrade to the SecureSphere Database Security Gateway. No other product on the market can match the full endto-end security inspection and activity auditing capability offered by this combination. Database communications via SQL protocols are one of the most common proprietary protocols used to transport data to and from Web applications, making this capability critical to a PCI strategy. Additional layers of security-- through SecureSphere s built-in network firewall and IPS layer -- also contribute to inspection of HTTP traffic independent of the protocol.

6 Recommended Capabilities (continued) 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. Encrypted data streams cannot be inspected unless SSL is terminated ahead of the inspection engine. SecureSphere is delivered as an appliance with software and operating system included. SecureSphere s operating system and security settings have been designed to protect against any attacks specifically targeting it. Imperva regularly performs internally reviews of product security (led by our world-class security research team, the Imperva ADC) and also has been independently tested and certified, most recently by the ICSA Labs. SecureSphere supports the broadest and most flexible range of options for inspecting encrypted Web traffic. This includes: SecureSphere can terminate SSL/TLS for inspection. SecureSphere can transparently decrypt SSL/TLS encrypted traffic for inspection SecureSphere can be transparently deployed behind an external termination device to inspect unencrypted traffic. Additional Recommended Capabilities for Certain Environments Prevent and/or detect session token tampering, for example by encrypting session cookies, hidden form fields or other data elements used for session state maintenance. Automatically receive and apply dynamic signature updates from a vendor or other source. In the absence of this capability, there should be procedures in place to ensure frequent update of WAF signatures or other configuration settings. SecureSphere supports multiple methods for preventing session-based attacks. This includes: Non-intrusive mechanisms that track and verify end-users have not modified or tampered with session variables/tokens. Session virtualization via signing session tokens (e.g. cookies). Signature updates are provided automatically to SecureSphere customers through the Application Defense Center (ADC), Imperva s internationally recognized security research organization. The ADC tracks all known attacks via a variety of industry sources as well as provides its own advanced protection signatures and protocol compliance rules for application and database vulnerabilities.

7 Additional Recommended Capabilities for Certain Environments (continued) Fail open (a device that has failed allows traffic to pass through uninspected) or fail closed (a device that has failed blocks all traffic), depending on active policy. Note: Allowing a WAF to fail open must be carefully evaluated as to the risk of exposing unprotected web application(s) to the public Internet. A bypass mode, in which absolutely no modification is made to the traffic passing through it, hmay be applicable in some circumstances. (Even in fail open mode, some WAFs add tracking headers, clean up HTML that they consider to violate standards, or perform other actions. This can negatively impact troubleshooting efforts.) SecureSphere has been designed to provide for a flexible range of options to reduce or eliminate the potential impact of a failure on protected systems. In addition to a full range of high availability modes, SecureSphere supports both fail open and fail closed options. Administrators can configure which option is best for their environment. In addition, SecureSphere s transparent modes are truly transparent and do not introduce the sorts of troubleshooting complications described in this item. In certain environments, the WAF should support Secure Sockets Layer (SSL) client certificates and proxying client authentication via certificates. Many modern Web applications use client SSL certificates to identify end users. Without this support, these applications cannot reside behind an application firewall. Many modern application firewalls will integrate with Lightweight Directory Access Protocol or other user directories and can even perform initial authentication on behalf of the underlying application. SecureSphere supports and protects Web applications that use client certificate authentication in various modes. In transparent modes, SecureSphere passes the authentication without modification. In proxy mode it can actively authenticate and proxy client certificate authentication. SecureSphere also can provide authentication that integrates with external directories and authentication solutions such as RSA Secure Access manager. Some ecommerce applications may require FIPS hardware key store support. If this is a consideration in your environment, make sure that the WAF vendor supports this requirement in one of their systems and be aware that this feature may drastically increase the cost of the solution. SecureSphere authenticates to FIPS certified Hardware Security Module (HSM) from SafeNet and ncipher. SecureSphere supports FIPS level II and III SSL implementations by interfacing to an HSM. In many cases, customers can use existing HSM hardware for this purpose to eliminate the need for additional cost.

8 Additional Considerations While WAFs can protect against many security threats, they may also expose technical problems within an infrastructure. Be sure to watch out for the following issues that may hinder successful deployment: Sites that rely on unusual headers, URLs, or cookies may require special tuning. WAFs often enforce maximum sizes for these components. Additionally, the signatures they look for may filter out specific strings perceived as exploits that in fact may be perfectly valid for a specific application. Content that does not conform to HTML/HTTP RFCs or is otherwise unusual may also be blocked without tuning of the default filters. This could include anything from overly large file uploads to content submitted in foreign character sets or languages. DHTML, Asynchronous JavaScript and XML (AJAX), and other dynamic technologies may require special consideration, testing, and tuning. These applications sometimes assume they have access to a web site in a way is perceived as malicious by a WAF. Applications that require information about the underlying network session, such as client IP address, may require modification if the WAF acts as a reverse proxy. Generally these WAFs will place client-side information into an HTTP header, which existing applications may not expect. SecureSphere s protocol validation mechanisms do inspect for such variances in the use of HTTP protocol elements. The validation engine is very flexible and completely configurable so that SecureSphere customers can change any problematic thresholds and even set exceptions on a per application basis. As above, SecureSphere s validation engine provides for the granularity and exceptions needed for real-world deployment. SecureSphere protects Web applications from new and emerging application threats that take advantage of the dynamic nature of Web applications. These include DHTML and AJAX applications. SecureSphere mitigates threats using a combination of security models including implementing server side input validation, session management/state tracking (prevention of cookie tampering), and applying access controls (preventing directory traversal and forceful browsing). To learn more about these types of dynamically changing applications and suggestions on how SecureSphere can be used to defend against related threats, refer to the Imperva white paper, Understanding Web 2.0: Technologies, Risks and Best Practices For applications that require information about the underlying network session and that aren t capable of interpreting x-forwarded-for headers, SecureSphere can be deployed transparently so that no modification to client-side information is needed.

9 Important Considerations Code reviews and application vulnerability assessments described in this document should be performed prior to implementing the application in production. If a WAF fail open or bypass mode is being considered, specific procedures and criteria defining the use of these higher-risk modes should be established prior to implementation. Web applications are not protected while these modes are active, and long periods of use are not recommended. The impact of web application firewall changes must be assessed for potential impact to relevant web applications, and vice versa. Communicate timing and scope of production web application firewall changes to all affected parties throughout the organization. Adhere to all policies and procedures including change control, business continuity, and disaster recovery. Changes to the production environment should occur during a monitored maintenance window. As described above, Imperva agrees that these techniques are an important part of an overall security program. This comment only serves to emphasize the issues that arise when protecting applications already in production, for which Web Application Firewalls are the best option. As above, SecureSphere can be configured for high availability (fail-over), fail open and fail closed. This provides the widest range of options to support organizational policy. SecureSphere s management console can be configured to alert administrators when a device fails so that the immediate action can be taken by security response teams. SecureSphere has been designed with ease of deployment in mind. As such, the range of flexible deployment modes usually means that SecureSphere will not impact Web applications or network configurations. SecureSphere s management server can be configured to notify administrators of changes as well as to integrate with change management applications. Imperva agrees that this is a sound Best Practice that should be followed by organizations. Imperva agrees that this is a sound Best Practice that should be followed by organizations. Imperva agrees that this is a sound Best Practice that should be followed by organizations.

10 About Imperva Imperva, the leader in application data security, delivers activity monitoring, real-time protection, and risk management solutions for business applications and data. Imperva s practical solutions provide full visibility into sensitive data, database and application access, enabling granular control and maintenance of critical data. Over 4500 of the world s leading enterprises and government organizations in over 35 countries rely on Imperva s automated, scalable and business-relevant solutions to prevent data theft, data abuse and ensure data integrity. US Headquarters International Headquarters 3400 Bridge Parkway 125 Menachem Begin Street Suite 101 Tel Aviv Redwood Shores, CA Israel Tel: (650) Tel: Fax: (650) Fax: Imperva, Inc. All rights reserved. Imperva and SecureSphere are registered trademarks of Imperva, Inc. Dynamic Profiling is a trademark of Imperva, Inc. All other brand or product names are trademarks or registered trademarks of their respective holders.