In this, the second installment in a series discussing common PCI compliance challenges, I address non-compliant payment applications. Such applications are nearly ubiquitous in the cardholder data environments of smaller merchants (and even some of the larger ones). However, merchants that store cardholder data are rarely able to attain a compliant state when using an application that has not been validated as compliant with PCI standards (either the older Payment Application Best Practices, or PABP, and the newer Payment Application Data Security Standard, or PA-DSS). In particular, compliance with much of PCI DSS Requirement 3, which deals with protection of stored cardholder data, is difficult or even impossible for these businesses, in many cases due to their payment application(s). Typically, such merchants have three options: migrate to a validated solution, work with the vendor of the current application and encourage them to have the application validated, or implement the required controls themselves. Because these applications pose such a high risk to cardholder data, Visa has mandated that all merchants will be required to use validated payment applications, with a deadline established for July 2010 in the U.S. and Canada and July 2012 for other regions. In the meantime, there are several things a merchant can do to meet DSS requirements, the Visa mandate notwithstanding.
In most situations, the best solution is to change the payment application and implement a solution that has already been validated. While this can be a daunting task, especially for larger or distributed environments, it is typically the solution with the most immediate payoff in terms of compliance, especially considering the impending Visa requirement. Chances are good that, if the current application has not been validated, there is a similar application that has been. By migrating to an application that has already been validated, and configuring systems to the standards outlined in the application’s implementation guide, merchants find compliance with DSS requirements much easier.
If moving to a different solution is simply not feasible, though, merchants should pressure payment application vendors to attain PA-DSS compliance by having the application validated by a PA-QSA firm (see https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf). Such a process can take quite a bit of time, which would delay the merchant’s ability to validate PCI DSS compliance. Also, modifying the application can also be expensive for the vendor. However, vendors of these applications should keep in mind that their customer base needs to attain and maintain compliance and it will become increasingly difficult to market and sell non-compliant payment solutions (see http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html).
If a payment application vendor is unable to meet compliance with PA-DSS requirements, merchants may be able to implement a number of controls to meet the PCI DSS requirements. Exactly which controls need to be applied will vary depending on the application, but some key areas can include eliminating storage of sensitive authentication data, obfuscating stored primary account numbers using encryption, hashing, truncation, etc., PCI data discovery on payment systems and servers, increased access controls and logging outside of the application, and implementing key management processes and technologies. Essentially, the payment application would be treated as an internally-developed application, and the merchant would be responsible for ensuring all controls are in place to protect cardholder data. In many cases, the cost of implementing these controls will outweigh the cost of changing payment applications.
When considering these options, merchants should ask an additional question: “Do I actually need to store cardholder data?” In many cases, smaller merchants can be forced to complete the lengthy Self-Assessment Questionnaire D due to the fact that a single application or point-of-sale stores credit card data. These merchants should note that slightly altering their business processes and replacing such a system with one that does not store cardholder data can pay dividends, as compliance requirements would be drastically reduced.
Looking over the findings of the last few dozen PCI gap assessments that NetSPI has performed, I am struck by the fact that today, well into version 1.2 of the Payment Card Industry Data Security Standard (PCI DSS, or just DSS), one of our most common findings remains increased scope due to lack of network segmentation. For example, we have seen numerous merchants with relatively simple payment processing environments that have a very large and complicated PCI scope and must bear the associated costs (e.g., develop and apply hardened system configurations, pay for external scanning services, etc.). In some cases, the merchant may not even have a real business need to store cardholder data (i.e. they could simplify their business processes and complete a Self Assessment Questionnaire C rather than the much longer SAQ D) but, even if they do, the scope of compliance is often far larger than necessary. Limiting the scope of the systems that are required to meet PCI DSS compliance gives merchants and service providers the best “bang for their buck” in terms of reaching their compliance goals, yet it seems that many merchants struggle with defining and implementing the controls necessary to do just this.
The first step in reducing the PCI scope through segmentation is to determine exactly which systems store, process, or transmit cardholder data. While this may be very straightforward for some organizations, it may be helpful to create a cardholder data flow diagram for more complex environments. Once cardholder data systems have been identified, a process of isolation and segmentation can begin. Ideally, cardholder data systems should be segregated off in a “PCI island” by a stateful firewall; Internet-facing systems should be placed in a separate DMZ segment. Once these major changes have occurred, locking down and documenting the firewall ruleset, implementing the necessary management processes, and other items detailed in Requirement 1 are much easier to address.
Though this process may look simple on paper, it can often involve the rearchitecture of not just the network but also individual systems, as PCI-related applications and functions should be isolated from other business functions (e.g., a database containing a parts inventory along with invoicing and payment information should be separated into individual databases in isolated network zones). However, through proper segmentation, merchants and service providers can significantly reduce the cost and scope of compliance and need only apply the DSS to systems and devices that store, process, or transmit PCI data.
In simple terms, IP traceback allows for the reliable identification of the source of IP traffic, despite techniques such as IP spoofing. While there are numerous methods for achieving this goal, they all have one thing in common: not one of these methods has actually been implemented in commercial networking equipment. Maybe its time has finally come.
The advantage of such a capability lies in determining the sources of one-way attacks, or attacks that can be conducted using spoofed source IP addresses. Unlike Reverse Path Forwarding, which can prevent address spoofing in limited environments, IP traceback essentially allows packets to be postmarked with the true source IP address. Denial-of-service (DoS) attacks are the most common type of malicious traffic that falls into this category. Although they don’t usually get the sort of visibility that they used to, DoS attacks still occur with astonishing frequency. While there are other methods for determining the source of spoofed traffic, they are typically time-consuming and require the involvement of numerous upstream parties. IP traceback could allow a network administrator to determine the source of such malicious traffic.
In a grad school paper I wrote a few years ago, I argued that “without the support of major networking equipment vendors or ISPs, and barring a major attack with far-reaching consequences, there is little hope for IP traceback in the near future.” Today, the question is when do we reach the point that the ability to reliably track the source of malicious IP traffic is deemed important enough to demand a feature such as IP traceback? Such an ability is more important than ever.
At the same time, there is a question of how effective such a solution would be if it were only partially implemented. Getting ISPs in North America and Europe to implement such a feature is a big enough step, but what practical value would IP traceback have if it were not implemented at the sources of much of the world’s malicious traffic: places like eastern Europe, Russia, China, and North Korea?
Despite such a potential limitation, I believe that there is a still a place for IP traceback in our networks. A software-based solution, which would require only firmware or driver updates, would be relatively inexpensive and simple to deploy. At the same time, it would assist network administrators and law enforcement in investigating attacks that use IP spoofing techniques, thereby creating an effective deterrent against such attacks.
On November 8, CBS’s “60 Minutes” ran a segment on information security weaknesses called “Sabotaging The System.” This piece highlighted security vulnerabilities in segments of our nation’s critical infrastructure, including banking, power, and national defense. In addition, former and current government officials confirmed that the threats exist; not only are probes and attacks occurring with alarming frequency, but there have been numerous documented instances of successful penetrations into all three of these sectors. The potential impact of such attacks ranges from the theft of a few million dollars to large-scale power outages or compromise of military secrets. In short, our nation is faced with a significant set of risks, and I feel that “60 Minutes” did justice to the severity of the problem. It is clear that the United States has benefited greatly from the interconnection of computer systems but, at the same time, we place ourselves at great risk by leaving these systems unprotected.
At the same time, the program was lacking with regard to solutions. There is nothing about these vulnerabilities that prevents them from being mitigated; IT security professionals solve similar problems every day. In this case, it is simply the scale of the problem that is most daunting.
President Obama recently raised the issue and classified our nation’s critical digital infrastructure as a strategic asset. This is the first step along the lengthy road toward a more secure infrastructure, but it is important in that it allows the power of the federal government to be brought to bear. As it stands today, many of the requirements for both private industry and government are inconsistent, vague, and toothless. In the future, though, we will likely see increased regulation of these (and other) critical sectors.
Regulation, though, is only part of the solution, and constriction of industry by over-regulation is a very real concern. By taking the initiative to combat vulnerabilities in their own environments, companies in these sectors can not only reduce the burden that eventual regulation will bring, but they can also demonstrate to regulators and lawmakers that they are taking the risk seriously. While that may be a novel approach for some, there will undoubtedly be benefits to swift action. Rather than waiting for government to force them to do something undesirable, businesses should revisit and re-architect their current approach to information security and risk management: examine the security framework that is used, alter how security is organized at the company, identify critical assets, analyze current controls, and finally mitigate vulnerabilities by implementing additional policies, processes, and technologies. There is no question that this sort of initiative will cost money but, in the long run, it will be money well spent.
Subscribe