Document Comparison
infosupp_6_6_applicationfirewalls_codereviews.pdf
→
information_supplement_6.6.pdf
85% similar
8 → 8
Pages
2981 → 2918
Words
19
Content Changes
Content Changes
19 content changes. 9 administrative changes (dates, page numbers) hidden.
Added
p. 2
Requirement 6.6 Option 1: Web Application Vulnerability Security Assessment Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities such as those listed in Requirement 6.5, multiple possible solutions may be considered. They are dynamic and proactive, requiring the specific initiation of a manual or automated process. Properly implemented, these alternatives could meet the intent of Requirement 6.6 and provide the minimum level of protection against common web application threats:
Information Supplement: Payment Card Industry Data Security Standard (PCI DSS) Requirement 6.6 Code Reviews and Application Firewalls Assessments may be performed by a qualified internal resource or a qualified third party. In all cases, the individual(s) must have the proper skills and experience to understand the web application, know how to evaluate it for vulnerabilities, and understand the findings. Individuals using automated tools must have the skills and knowledge to properly configure the tool and …
Information Supplement: Payment Card Industry Data Security Standard (PCI DSS) Requirement 6.6 Code Reviews and Application Firewalls Assessments may be performed by a qualified internal resource or a qualified third party. In all cases, the individual(s) must have the proper skills and experience to understand the web application, know how to evaluate it for vulnerabilities, and understand the findings. Individuals using automated tools must have the skills and knowledge to properly configure the tool and …
Added
p. 7
• Web Application Firewall Evaluation Criteria (Web Application Security Consortium) The intent of the document is to provide supplemental information. Information provided here does not replace or supersede Requirement 6.6 of the PCI Data Security Standard (DSS).
Removed
p. 2
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.
Requirement 6.6 Option 1
• Application Code Reviews The application code review option does not necessarily require a manual review of source code. Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level …
Requirement 6.6 Option 1
• Application Code Reviews The application code review option does not necessarily require a manual review of source code. Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level …
Modified
p. 2
PCI DSS Requirement 6.6 provides two options that are intended to address common threats to cardholder data and ensure that input to web applications from untrusted environments is inspected “top to bottom.” The details of how to meet this requirement will vary depending on the specific implementation supporting a particular application.
PCI DSS Requirement 6.6 provides two options that are intended to address common threats to cardholder data and ensure that input to running web applications from untrusted environments is inspected “top to bottom.” By “running,” we mean the application has been deployed in an operational environment, including production, or acceptance-testing/pre-production environments with associated strong change control processes. The details of how to meet this requirement will vary depending on the specific implementation supporting a particular application.
Modified
p. 2
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. (Refer to the References section for other sources of information on web application testing.) Proper implementation of both options would provide the best multi-layered defense.
The intent of Requirement 6.6 is to ensure web applications exposed to the public Internet are continually protected against the most common types of threats while running and accepting 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. (Refer to the “Additional Sources of Information” section for other reference material on web application testing.) The ideal multi-layered defense would include proper implementation of both options …
Modified
p. 2
1. Manual review of application source code
1. Manual web application security vulnerability assessment
Modified
p. 2
2. Proper use of automated web application security vulnerability assessment (scanning) tools These must be designed to test for the presence of web application vulnerabilities as indicated under “General” above. Note that a vulnerability assessment simply identifies and reports vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible.
Removed
p. 3
There are several ways to perform a code review or application assessment that would provide the same (or better) protection provided by an application firewall ( discussed below as Option 2). Two examples that may meet the intent of the first option are:
1. An organization’s having in place, as part of its software development life cycle (SDLC), a process whereby web application source code undergoes an independent security review. The security review should consist of examining applications for controls that address common web application vulnerabilities. These code reviews may be implemented as manual or automated processes.
The reviews or assessments should be incorporated into the SDLC and performed prior to the application’s being deployed into the production environment. The SDLC must incorporate information security throughout, per Requirement 6.3. Change control processes must ensure that software developers are not able to bypass the code review/application assessment step and deploy new software directly …
1. An organization’s having in place, as part of its software development life cycle (SDLC), a process whereby web application source code undergoes an independent security review. The security review should consist of examining applications for controls that address common web application vulnerabilities. These code reviews may be implemented as manual or automated processes.
The reviews or assessments should be incorporated into the SDLC and performed prior to the application’s being deployed into the production environment. The SDLC must incorporate information security throughout, per Requirement 6.3. Change control processes must ensure that software developers are not able to bypass the code review/application assessment step and deploy new software directly …
Modified
p. 3
If internal resources are being used, they should be organizationally separate from the management of the application being tested. For example, the team writing the software should not perform the final review or assessment and verify the code is secure.
If internal resources are being used, they should be organizationally separate from the management of the application being tested. For example, a development team that writes a web application should not perform the final security assessment.
Modified
p. 3
The assessment may use a manual process or specialized tools to test for the presence of exposed vulnerabilities and defects in an executing web application. This approach involves creating and submitting malicious or non-standard input to the application, thus simulating an attack. The responses to that input are examined for indications that the application may be vulnerable to certain attacks.
Removed
p. 4
IP packet structure follows a layered model, with each layer containing defined information that is acted upon by specific network nodes or components (physical or software-based) supporting the flow of information through the Internet or intranet. The layer containing the content that is processed by the application is called the application layer.
Modified
p. 4
Requirement 6.6 Option 2
• Application Firewalls In the context of Requirement 6.6, an “application firewall” is a web application firewall (WAF), which is 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.
•
Requirement 6.6 Option 2: Web Application Firewalls A web application firewall (WAF) is 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.
Modified
p. 4
WAFs are designed to inspect the contents of the application layer of an IP packet, as well as the contents of any other layer that could be used to attack a web application. It should be noted, however, that Requirement 6.6 is not intended to introduce redundant controls. IP packet content adequately inspected (i.e., providing equivalent protection) by network firewalls, proxies, or other components do not have to be re-inspected by a WAF.
IP packet structure follows a layered model, with each layer containing defined information that is acted upon by specific network nodes or components (physical or software-based) supporting the flow of information through the Internet or intranet. The layer containing the content that is processed by the application is called the “application layer.” WAFs are designed to inspect the contents of the application layer of an IP packet, as well as the contents of any other layer that could be used …
Modified
p. 4
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.
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 systems,” “secure proxies,” 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.
Modified
p. 5
• 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.
• 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 are not otherwise inspected at another point in the message flow.
Modified
p. 5
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.
Note: Proprietary protocols present challenges to current web 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 a web application firewall inspect that specific message flow. In these cases, implementing the vulnerability assessment option of Requirement 6.6 is probably the better choice.
Modified
p. 6
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, may 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.)
Modified
p. 6
• 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.
• 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 a web application firewall. Many modern web application firewalls will integrate with Lightweight Directory Access Protocol (LDAP) or other user directories and can even perform initial authentication on behalf of the underlying application.
Modified
p. 7
• Code reviews and application vulnerability assessments described in this document should be performed prior to implementing the application in production.
• The application vulnerability assessments described in this document should be performed prior to implementing the application in production.