Feature

Understanding How to Protect Web-facing Applications

Under the Covers of Requirement 6.6 of PCI
sushila nair, cisA, cisM, cissp, is a product manager at BT Counterpane and is responsible for compliance products. Nair brings 20 years of experience in computing infrastructure, business security and a diverse background. She has worked with the insurance industry in Europe and the US on methods of quantifying risk for e-insurance based on ISO/IEC 27001. Doug Drew, cissp, pci QsA, is a senior security consultant with BT INS. He has been working with PCI DSS since 2006 and has conducted numerous PCI engagements for BT INS, covering a diverse range of industries. Drew specializes in risk management, regulatory compliance and security program development. peter Verderber, cisA, cissp, pci QsA, is a principal consultant with BT INS and has more than 10 years of experience in the field of information security. Verderber specializes in risk management and compliance, helping organizations effectively address information security from a business perspective.

The Payment Card Industry (PCI) Data Security Standard (DSS) is an excellent standard around which to build a data protection framework. The standard is built on analysis of data security breaches and the requirements are built around preventing the top sources of data loss. The standard does not guarantee data security, but it ensures that sensible controls are put in place to prevent the majority of the causes of security breaches. Since February 2005, according to the data available on Privacy Clearing House, 140 million records have been breached and approximately 80 million of these were due to web hacking attacks. Any organization that is concerned about data breaches must be aware of the risks associated with web-facing applications. It is clear that the forensics on data breaches done by the card companies have pointed to web-facing applications as a high area of risk and, therefore, the standard has incorporated controls to reduce this risk. This article focuses on section 6.6 of DSS, which aims to protect organizations from data loss/breaches through web-facing applications. In June 2008, the PCI Security Council began enforcing section 6.6 of the DSS, which states: Ensure that all web-facing applications are protected against known attacks by either of the following methods: aving all customer application code H reviewed for common vulnerabilities by an organization that specializes in application security nstalling an application-layer firewall in I front of web-facing applications

Attacks on web-facing applications are common and often successful, and are allowed by poor coding practices. This requirement for application code reviews or applicationlayer firewalls is intended to greatly reduce the number of compromises on web-facing applications that result in breaches of cardholder data. ApplicAtion VulnerAbilities Requirement 6.6 is based on the assumption that most internally developed code is considered untrustworthy, i.e., applications that are developed in-house are not subject to the same level of application testing that thirdparty vendors conduct. (It is interesting to note that in spite of the large budgets reserved for application testing by software companies, many new software vulnerabilities are announced almost daily. This highlights the importance of application testing for organizations that have neither the inherent skill set required nor the bandwidth to conduct the same level of testing.) There have been several theories about the relationship between the number of source lines of code (SLOC) and coding errors. The relationship between the two is dependent on the language, quality assurance process, testing and other quality control factors. However, it is obvious that the larger and more complex the application, the greater the likelihood for programming errors. Classic vulnerabilities range from an online bookstore that did not test for customers who would enter negative numbers for purchases and, thus, credited customer bank accounts upon purchase, all the way to web pages that have revealed personally identifiable information (PII) of customers. Most developers will admit to developing for functionality, with security simply 1

The intent of the section is to protect against application vulnerabilities. The guidance on interpreting the standard clarifies this requirement further by stating:

ISACA JOURNAL VOLUME 4, 2009

being an afterthought. A good development practice does help reduce the number of bugs, but it simply cannot eradicate human error. The results of coding errors can carry significant risk, especially with those applications that are business-critical and store confidential data. In its Q3 2007 Application Security Trend Report, Cenzic, an applications security testing specialist organization, details 1,471 unique, published vulnerabilities it observed, with cross-site scripting (XSS) and Structured Query Language (SQL) injection standing as the most prevalent issues resulting from poor coding. The most recent report estimates that 71 percent of all the vulnerabilities reported worldwide during the fourth quarter of 2007 were related to web applicationsaffecting everything from servers to browsers and representing a 3 percent increase over the previous quarter. Even worse, Cenzic contends that roughly 70 percent of all reported web applications vulnerabilities could be classified as trivially exploitable. coDe reViews One possible solution for reducing the risk associated with vulnerabilities in web applications is code reviews. Code reviews can be done manually or through the use of automated tools. Doing a code review for an application that has been working uninterrupted for years (as is often the case) usually proves futile. Often the coders are not there anymore, the coding language is obsolete and the business impact of touching the application may be higher than the fines involved in not being compliant. Ethical hacking can be used as a method of testing the applications security and may be more effective than a review of source code. Ethical hacking will reveal application vulnerabilities and should be performed by a company that has a proven track record within this arena. web ApplicAtion FirewAlls Another possible solution for protecting web applications is to use a web application firewall (WAF). WAFs are designed to make fine-grained decisions about traffic based on rule sets. These security devices have extra intelligence compared to network perimeter firewalls and the ability to learn. Early WAFs had issues surrounding performance, because deep packet inspection by its nature results in slower throughput. There are three major categories of vendors offering WAFs: optimization platform vendors, such as F5 Networks Inc.; network perimeter vendors, such as Check Point Software 2
ISACA JOURNAL VOLUME 4, 2009

Technologies; and application- and database-aware hybrids that protect the web application and the database, such as Imperva Inc. All of these firewalls have the capability of understanding application-layer traffic and can protect against application attacks, such as SQL injection. Most WAFs have standard signatures to protect against well-known attacks, such as worms and SQL injection attacks. These devices also have the capability to learn how users access web pages and can alert or block unusual access, such as entry of an SQL command into an input field, thus preventing an SQL injection attack in a poorly coded application that did not do input validation correctly. The learning component, called profiling by some vendors, also provides protection against zero-day attacks, which may not have a signature associated with the attack pattern. Figure 1 shows how to set access parameters around input from the WAF without making any changes to the application itself. Since WAFs do content inspection, they can also be used for inspecting and alerting to types of data being accessed, i.e., credit card numbers or other confidential data. Some WAFs provide support for Secure Sockets Layer (SSL) by allowing the key to be loaded on to the WAF, and, thus, encrypted traffic as well as standard HTTP can be inspected. Criticisms of WAFs include the difficulty of deploying and tuning these devices. However, this market is gradually improving. The classic WAF is simply performing fine-grained inspections of packets and, if required, blocking traffic that is deemed to be in some way dangerous. This obviously can be achieved by an intrusion prevention system (IPS). WAFs, however, like all security products, are taking additional security enhancements, such as database application monitoring (DAM), code review and policy enforcement, to a data content level. It is likely that WAFs will converge with Extensible Markup Language (XML) security gateways. There are enormous benefits in protecting data with devices that understand content of the data, including the ability to enforce data protection framework policies, such as those for US Social Security numbers and credit card numbers, and to be able to protect from common application-layer attacks. issues with wAFs When customers deploy the application-level protection in their network firewall, they often wonder whether missing the additional protections available by WAFs puts them in danger. The answer is not that clear, especially since the configuration

Figure 1setting Access parameters with wAF

of most WAFs is so complex that they often give the user a false sense of security. Moreover, WAFs do nothing to reduce the risks in which vulnerabilities (bugs) in applications themselves result (essentially, arbitrary downstream events, such as unrestricted database queries). At the end of the day, the question that customers need to ask themselves is whether their application can be manipulated in such a way that the payment card information residing in the database layer can be compromised. It can be argued that positioning an application-aware network firewall in front of the web application and a good monitoring and attack prevention system on the database layer is the most practical solution with the most predictable security outcome. DAtAbAse ApplicAtion Monitoring DAM and protection helps customers comply with other sections of PCI DSS (including sections 2, 3, 7, 8, 10, 11 and 12) and the same is true for network firewalls (mandated by section 1). A highly effective and arguably much better alternative for a WAF is the combination of DAM, an IPS and an effective firewall. A good database monitoring and prevention system in the database layer (provided by vendors such as Sentrigo, Secerno, Tizor and Guardium) can help stop attacks that

have somehow made it through the firewall and reached the database. For example, by merely protecting the dictionary tables of databases, a prevention system can thwart most attacks that begin by trying to figure out the structure of the databases (to find the way to the payment card information). Vendors who are able to inject the original application user and URL add another layer of protection by limiting (for example) the ability of some users to access or make changes to cardholder tables. Some systems offer fine-grained access policies with deterministically zero false-positives that enable only acceptable queries to critical database tables. issues with DAM DAM can be challenging to deploy as it requires tuning. The complexity of the solution varies from vendor to vendor, but to get real value from the products, the software needs to be configured and alerts need to be defined to ensure that sensitive data loss is monitored appropriately. One of the other problems with DAM is the inability of products to track the identity of the end user who is accessing the database. Most web applications are configured to log in to the database using a single account; therefore, any product that is monitoring the database will not see the end user accessing the data, but rather the account configured on the web server.
ISACA JOURNAL VOLUME 4, 2009

Most DAM solutions offer work-arounds to this problem with varying levels of success. One of the very innovative solutions is combining web application monitoring with DAM from a single vendor, such as the solution offered by Imperva. This provides a solution that combines the strength of WAFs and database monitoring and provides user tracking. choosing A solution WAFs and DAM are not an excuse for careless development practices. They are, however, excellent solutions for reducing the risk of web application vulnerabilities. Both solutions are complex, but as attacks become more complex and difficult to discover, a solution that provides the capability to monitor is extremely important. In the case of the large credit card breaches at Hannaford and TJX, the data loss was discovered by the bank and not the merchant. And, both organizations implemented monitoring solutions after the breaches were discovered. It makes sense to implement a solution that monitors for data loss before the organization hits the headlines in a similar manner. DAM does not stop the application server from being compromised and being used as a launch pad into the database. However, threats from the outside world are only one avenue of attack. There is a clear argument that the control should be as close as possible to the asset, so that all avenues are protected. The move away from signature-based attack detection to anomalous access or behavioral access to the asset results in the widest range of detection of attacks, though the tuning may be more complex initially. Code review is a very important component of application security quality assurance. The code review should be conducted by a third party that specializes in this area; desk checking or having a trained colleague wading through lines of code is unlikely to reveal application flaws. In particular, code review should concentrate on the threat to critical data in databases, which can be achieved accurately and completely only by measuring actual database access, e.g., using database behavioral analysis tools, such as Secernos. Ethical hacking is arguably the most effective method of code review. Ethical hacking is a highly skilled task, and it is best to select an ethical hacking company that has been rated by recognized agencies, such as the US National Security

Agency (NSA), rather than one that simply tells good war stories. It is possible to use an automated tool for code review, such as Coverity which was developed in the Computer Systems Laboratory at Stanford University in Palo Alto, California, USA, from 1998 through 2002. It makes sense, no matter what solution is chosen, that the organization should test that the solution works either by using a respected firm or by using ethical hacking. conclusion Application-level attacks are one of the top five causes of account data compromise. Good development practices may reduce bugs, but, as it is human to err, good procedures will never eradicate them. The PCI DSS requirement to install an application firewall is simply one way of protecting data. Organizations should not follow the mandate blindly, but rather determine what they are trying to achieve and ensure that they have a solution that fits into their monitoring security architecture and reduces risk without a corresponding increase in complexity. In conclusion, it can be argued that implementing a centralized monitoring framework with either an IPS and a DAM solution, or a WAF and a DAM, will result in the highest level of protection for the organizations critical asset. reFerences Imperva, www.imperva.com Sentrigo, www.sentrigo.com Secerno, www.secerno.com Burton Group, Web Application Firewall Market Maturing, http://searchsecurity.techtarget.com/news/ article/0,289142,sid14_gci1218724,00.html Cenzic, Q3 2007 Application Security Trend Report, www. cenzic.com/news_events/Cenzic_AppSecTrends_Q3-07.php Cenzic, 2008 Application Security Trend Report, www.cenzic. com/pdfs/Cenzic_AppSecTrends_Q1_2008.pdf Payment Card Industry, Navigating PCI DSS: Understanding the Intent of the Requirements, v1.1, https:// pcisecuritystandards.org/pdfs/navigating_pci_dss_v1-1.pdf

ISACA JOURNAL VOLUME 4, 2009