Monday, January 28, 2013
Monday, January 21, 2013
Sunday, January 20, 2013
Friday, January 18, 2013
Mitigating Point-of-Sale Security Risks
Chase Paymentech Highlights Compliance Efforts
By Jeffrey Roman, January 17, 2013. Follow Jeffrey @ISMG_News
Compliance with security mandates, such as the Payment Card Industry Data Security Standard, cannot fall solely on the shoulders of merchants, he says. Merchant vendors and others have roles to play as well.
"Less risk for merchants means less risk for us," he says. "We add value to our merchant relationships by playing an active role in helping reduce their risk by achieving and maintaining PCI compliance."
One of the greatest concerns in merchant security now is improperly installed or configured point-of-sale applications and devices, Wallace says, "particularly where third parties or remote-access is used."
It's a worry shared by the PCI Security Standards Council. In August, the council launched a new training program aimed at POS installers and integrators (see: PCI: new Approach to Merchant Security).
"[The program] provides training and qualification to ensure integrators and resellers have the expertise required to install and maintain applications in a secure manner," Wallace says.
"The QIR program is a direct response to what forensics investigators are seeing in the field," he adds. "It holds QIRs accountable for installing and configuring applications to facilitate their customer's PCI compliance via built-in quality assurance components."
During this interview, Wallace discusses:
- Why no single product, service or best practice renders a business secure;
- Why franchises and merchants in the hospitality space are often the most vulnerable;
- How the new PCI POS integrators and installers program is being rolled out in a way that's easy for merchants.
POS System Security
TRACY KITTEN: How is Chase Paymentech involved with this new PCI program?DAVID WALLACE: Chase Paymentech is a Payment Card Industry Security Standard Council participating organization and has been since the council was founded. We're a charter member of the PCI-SSC board of advisors and we continue to serve in that role today, helping to educate and protect our customers in our industry. We strongly advocate merchant adoption of standards-based information security programs that include compliance with the PCI-DSS and all applicable payment brand cardholder data security program rules. We were involved in the QIR program from the outset as member of the council's taskforce, and as an acquirer we see multiple areas of value to our merchants and our industry. We see participation as a market differentiator, providing competitive advantage to QIRs who train and certify through the program, and we see the advantages associated with our merchants having access to trained and accredited professionals who can help them achieve higher degrees of protection against an increasingly opportunistic, organized and technically sophisticated criminal threat.
KITTEN: What can you tell us about the merchants that you serve and the types of programs that you oversee?
Page 2 of 4)
WALLACE: Chase Paymentech is a payment processing and merchant acquiring business at JPMorgan Chase and Company. We combine payment technology along with merchant advocacy, such as our involvement in the Payment Card Industry Security Standards Council, which creates quantifiable values for companies large and small. In 2011, we processed more than 24 billion transactions with a value exceeding $553 million dollars. Our legacy of innovation and vision in electronic payments has long promoted the growth of e-commerce worldwide, and we continue to fuel the success of the Internet's largest brands as the No. 1 ranked provider in the payment processor category of Internet Retailer's Top 500 Guide for the seventh consecutive year.
My team manages merchant compliance with Payment Card Industry data security standards and PCI for over 1,000 of Visa and MasterCard Level 1, 2 and 3 card-present e-commerce merchants across the U.S., Canada and Europe. We co-sponsor multiple onsite trainings for our merchants with MasterCard in the U.S. and Canada annually, as well as co-sponsoring an internal security assessor certification training program with the PCI Council. We also publish white papers, newsletter articles, update bulletins, participate in interviews and podcasts such as this one, and provide PCI awareness and education presentations to dozens of merchant forums annually. Finally, we work directly with merchants via conference call or site visit to help them develop payment and security strategies that help them achieve and maintain PCI compliance.
Acquirer Responsibility
KITTEN: How much responsibility do acquirers bear when it comes to merchant security?WALLACE: As an acquirer, our success is inextricably linked to our merchants and our business partners who service them. Less risk for merchants means less risk for us. As such, we add value to our merchant relationships by playing an active role in helping reduce their risk by achieving and maintaining PCI compliance.
Top POS Concerns
KITTEN: What would you say are some of the top concerns that you see in POS security?WALLACE: One of the largest concerns and one of the reoccurring themes we see in security is the large percentage of compromises occurring because of badly installed or configured applications, particularly where third parties or remote access is used, making merchants vulnerable. Seventy-six percent of breaches were a result of security vulnerabilities introduced by a third party responsible for system support development or maintenance of business environments, according to the Trustwave 2012 Global Security Report. Badly configured POS systems are a target for automated attacks launched by criminals over the Internet. The Verizon 2012 Data Breach Investigation Report says that 85 percent of the breaches that occurred in 2011 involved POS terminals and servers. Adoption of payment application data security standard applications is a big step merchants can take to improve their security posture. PA DSS-validated applications provide built-in security controls supporting PCI-DSS compliance. Security maintenance and update capability to support maintaining compliance over the long term is also incorporated; but there's no benefit if they're not properly installed and maintained.
Small businesses are especially vulnerable to this. They have the least technology and security expertise, and that combination of a relatively low knowledge level and escalated risk means that data compromises are occurring more frequently among smaller merchants. They're an easier target. High on that list are franchises and hospitality industries. Common payments and technology infrastructures across locations mean that if a breach is identified, it can be exploited over and over. These locations usually have robust connectivity between the locations as well, which means that once a vulnerability is found, the preexisting connectivity can be used to jump from location to location to location exploiting that breach.
Qualified Installers
KITTEN: Does this program differentiate qualified installers and value-added resellers from others connected to the payments chain?
WALLACE: Yes. It provides training and qualification to ensure integrators and resellers have the expertise required to install and maintain applications in a secure manner. The QIR program is a direct response to what forensics investigators are seeing in the field, as I noted above from the Trustwave and Verizon security reports. It holds QIRs accountable for installing and configuring applications to facilitate their customer's PCI compliance via built-in quality assurance components. The QIRs receive annual re-certification training during their requalification process to keep their skills current, and they're also included on the PCI Security Standards Council site listing, which is a distinct marketing advantage for them and a differentiator from their competitors.
KITTEN: Can you talk about positive results that you've seen so far related to the program?WALLACE: Initially, we see the QIR certification as a differentiator. It indicates the exceptional level of service with which merchants should be expected to be provided. It provides merchants with a clear choice in partnering with providers who are as committed to their data security as they are. Beyond that, it's hard to say with the program so recently announced. The current goals are to grow awareness and drive adoption to ensure merchants and integrators realize the promise of those benefits.
Areas for Improvement
KITTEN: With that understanding in mind, have you identified any areas where you think the program could be improved?WALLACE: As we've said, this is a new program. The industry is giving it the best possible start, based on feedback from market stakeholders. We know from our experience with the PCI SSC's other standards and programs there will be growing pains and opportunities for improvement. That's why the council builds feedback and lifecycle management into all their programs, and those are being leveraged going forward. As the program is implemented, Chase Paymentech will provide feedback to the council on our experience, as well as relaying feedback from our industry stakeholders, including suggestions for improvement. We know the council will be counting on all the other industry stakeholders to do the same.
Other Group Interest
KITTEN: What other organizations or groups should take interest in this program?WALLACE: There are probably four groups who are absolutely directly affected by this. Certainly, [there are] the merchants, who are provided with vetted resources for installation and maintenance services. They can confirm their provider is trained and certified to support their PCI compliance efforts, and they can come away with an improved security posture and reduced risk of a cardholder security breach. The integrators and resellers, and third parties, as I mentioned, can add professional certifications in an industry-wide recognized certification to their credentials, and receive marketing exposure through the listing on the PCI SSC website.
Acquirers absolutely benefit from this by helping their merchants access these accredited professionals who can assist in securing their data and ultimately improve their business practices. Vendors as well can assure that the integrators and resellers of their applications are qualified and understand how PA DSS-validated payment applications should be installed in the field.
Common PCI Compliance Misconceptions
KITTEN: What would you say are the most common misconceptions merchants have when it comes to PCI compliance and POS security are concerned?WALLACE: There are a number of misconceptions. But, certainly, the main misconception is that purchasing a PA DSS-validated application and using it is all that needs to be done. These merchants many times have used an installer before and feel comfortable that installer knows what he's doing. I've heard, "I'm an e-commerce merchant. Payment application security isn't really my problem. It doesn't apply to me." I've heard, "We have a firewall. Compromises can't happen because the hackers can't get past it." There's also the ongoing perception in the world today that systems, applications and products are inherently secure or inherently insecure, and that's simply not the case.
QIR Program
KITTEN: How does this QIR program address some of those common merchant misconceptions?WALLACE: I performed my first security investigation in 1984, and the most common question I've been asked since that time is, "Is this or that particular product or service secure?" I wish that security were a single thing that was as simple as off or on. Security is comprised of many things. It's a comprehensive set of overlapping controls that provide defense in depth, and protection against the failure of any one control or another at some point in time. There's no single product, service or best practice that renders a business secure.
For example, using a PA DSS-validated application is an important part of a merchant's overall PCI compliance program; but it does not, in and of itself, make a merchant PCI compliant or secure. But PA DSS-validated applications are good things, very good things. They have been professionally assessed and confirmed to contain the PCI-DSS controls required to protect cardholder data at the point of payment. But if those controls are improperly configured or not enabled, they provide no protection. A QIR is trained to ensure a PA DSS-validated application is installed and configured, and, therefore, used in a PA DSS-compliant manner. PA DSS-validated payment applications run on computers and transmit data over networks. There are many PCI controls beyond PA DSS controls that apply to computers and networks. A QIR is also trained to identify these controls, determine if they're missing, and make the merchant aware of other vulnerabilities that may exist beyond his application. Applications have to be implemented, integrated, serviced and maintained according to PCI-DSS and PA DSS. The PCI-DSS, PA DSS and QIR programs are all complimentary programs to ensure that happens without introducing additional risks into the merchant's environment.
KITTEN: How do quality-assurance checks and balances introduced by this new program help to improve payment card security?
WALLACE: The program includes an implementation statement comprised of a checklist of activities the QIR completes during the installation of an application, providing a record both for the QIR and the merchant of steps taken to ensure the application has been installed securely. It's an opportunity for the QIR to record any risks to PCI-DSS compliance they wish to make their customer aware of. You start with a checklist.
Next, you have the feedback loop for merchants. They can provide feedback on their QIR installations using a form on the PCI website using a rating scale from one to five. The merchant scores the installer's performance and they may also provide comments as necessary. Finally, PCI SSC-accredited qualified security assessors evaluate the quality of a QIR installation where they're assessing a customer for PCI compliance whose application was installed and configured by a QIR. This provides a second independent review of the QIR's work by an objective set of trained eyes.
Future Opportunities
KITTEN: What opportunities do you see for this program, where communication, collaboration and a broader understanding of PCI standards across the industry is concerned?WALLACE: Security is defense in depth, and it's clear that merchants can't rely just on technology for security. They need to build security programs that address people and processes, too. In this program, the QIR program is all about improving the people who will be involved in merchant security. Certainly, the PCI-SSC member brands - Visa, MasterCard, American Express, Discover and JCB - will work to drive awareness and adoption of the program as well. Payment security is ultimately a shared responsibility. The QIR program is another tool in the payment card industry's toolbox to facilitate improved security across all of our stakeholders
Wednesday, January 16, 2013
Wednesday, January 9, 2013
Monday, January 7, 2013
Friday, January 4, 2013
Turktrust Certificate Authority Errors Demonstrate The Risk of “Subordinate” Certificates
3, 2013 By
Today, the public learned of another failure by a Certificate Authority–one of of companies that certifies SSL-encryption for our internet communications. (See the end of this post for a catalogue of our past writing on problems with this “CA” system.) This time, the company Turktrust was revealed to have issued two subordinate certificates (also known as “intermediate” certificates) to entities that should not have had them. Subordinate certificates are very powerful. They give the holder the ability to issue SSL certificates for any domain name as though they have control of the parent CA’s “root” certificate. In this case, Google discovered that one of Turktrust’s previously undisclosed subordinate certificates had issued SSL certificates for the domain gmail.com, and that these certificates had been used to intercept Gmail users’ traffic… somewhere. This is where the details get foggy, but Turktrust has begun to describe their version of events.
There is a less paranoid and a more paranoid way of interpreting what happened.
But first, for the geeks, here are the contents of the subordinate certificate that issued the gmail.com certificate. I don’t believe that this has been posted publicly so far (hat tip to Alex Halderman and his genius students/colleagues).
According to Turktrust, they made some configuration errors in late 2011 that caused them to inadvertently hand out subordinate certificates to two entities–the Turkish government and a Turkish bank. They claimed that these users expected to receive ordinary SSL certificates that could be used to secure their own web sites, not what amounts to a master “skeleton key” to the internet. This assertion is somewhat supported by the fact that one of these certificates appears to have been used for precisely that until recently, at www.ego.gov.tr (which seems to be the web site for the capital city of Ankara or one of its offices, but I’m sure that Zeynep will clear this up in the comments). Turktrust says that the certificate was used by the government to provide SSL-encrypted webmail–presumably for government employees (As a further side-note, it is unclear whether deploying subordinate certificates as though they are ordinary SSL certificates will cause some or all browsers to generate an error, but perhaps it worked for them). In any case, Turktrust says that a government system administrator recently loaded the certificate onto a “firewall” that proceeded to perform man-in-the-middle attacks on individuals who attempted to browse to secure web sites like gmail.com. It’s not clear what network this device was on (although it was evidently manufactured by Check Point), and which individuals were affected. The least paranoid version of suggests that the device sat between the government’s internal network and the public internet, and that the only individuals affected were government employees in that office.
The more paranoid version of events is perhaps less likely, but it helps to highlight some fundamental shortcomings in the Certificate Authority system. Subordinate certificates have long been identified as a point of weakness in the CA system. They are typically granted unconstrained power to issue certificates for any domain name. Thus, a leak of one subordinate certificate is seen as equivalent to a leak of authority equivalent to all CAs combined. Worse, subordinate certificates need not be explicitly trusted by the software that authenticates encrypted SSL connections (typically your web browser). They inherit their trust from the explicitly trusted CAs that have been vetted by your browser vendor. Browser vendors have slowly been trying to reign in the practices of CAs that issue subordinate certificates to third parties. For instance, when CA Trustwave admitted that it had been selling subordinate certificates to third parties for the purpose of performing man-in-the-middle attacks, Mozilla made clear that this was unacceptable. That being said, depending on your browser, there may be a couple hundred trusted CAs. Hoping that they all comply with a policy is probably not enough. I have spent the past couple of years trying to convince Mozilla to strengthen their requirements so that CAs must disclose all subordinate certificates that they have issued, so that researchers can better map the risk landscape and so that users can make more informed trust decisions and detect unexpected subordinates. They’re getting closer, but it is taking an awfully long time. Several years ago, security researchers Christopher Soghoian and Sid Stamm described the “compelled certificate creation attack” in which a government would compel a local CA to produce a subordinate certificate that it would then use to conduct mass or targeted man-in-the-middle surveillance on its citizens.
We are justified in indulging in a bit of professional paranoia, given that the Turktrust subordinate certificate in question was controlled by the Turkish government, and that it was used to perform man-in-the-middle attacks. It also happens to be the case that Turktrust satisfied its annual compliance audits by having the Turkish government audit their operations, as opposed to the more common practice of obtaining an audit from a commercial auditing firm (although they claim to have recently obtained a commercial audit, they have yet to publish any documentation of this as far as I can tell). Turktrust has begun to give some answers, but it’s worthwhile to keep probing.
Mozilla revoked trust in one of Turktrust’s three “root” CA certificates, as did Google–but oddly the revoked root is not the certificate that issued the subordinate certificates in question. It is a new root certificate (included in Firefox only in beta releases so far), and it is intended to be used only for issuing higher-standard “extended validation” certificates. It appears that the browsers’ strategy is to provide some mild punishment to Turktrust without disrupting the operation of legitimate sites that have obtained standard SSL certificates from them in the past. Representatives from both browser vendors have stated that it is unclear how they will proceed, and one can imagine that they would restore trust in this root at some point in the future. Is Turktrust’s behavior sufficient that trust in all three of their roots should instead be removed permanently? The facts are still emerging.
There is a less paranoid and a more paranoid way of interpreting what happened.
But first, for the geeks, here are the contents of the subordinate certificate that issued the gmail.com certificate. I don’t believe that this has been posted publicly so far (hat tip to Alex Halderman and his genius students/colleagues).
According to Turktrust, they made some configuration errors in late 2011 that caused them to inadvertently hand out subordinate certificates to two entities–the Turkish government and a Turkish bank. They claimed that these users expected to receive ordinary SSL certificates that could be used to secure their own web sites, not what amounts to a master “skeleton key” to the internet. This assertion is somewhat supported by the fact that one of these certificates appears to have been used for precisely that until recently, at www.ego.gov.tr (which seems to be the web site for the capital city of Ankara or one of its offices, but I’m sure that Zeynep will clear this up in the comments). Turktrust says that the certificate was used by the government to provide SSL-encrypted webmail–presumably for government employees (As a further side-note, it is unclear whether deploying subordinate certificates as though they are ordinary SSL certificates will cause some or all browsers to generate an error, but perhaps it worked for them). In any case, Turktrust says that a government system administrator recently loaded the certificate onto a “firewall” that proceeded to perform man-in-the-middle attacks on individuals who attempted to browse to secure web sites like gmail.com. It’s not clear what network this device was on (although it was evidently manufactured by Check Point), and which individuals were affected. The least paranoid version of suggests that the device sat between the government’s internal network and the public internet, and that the only individuals affected were government employees in that office.
The more paranoid version of events is perhaps less likely, but it helps to highlight some fundamental shortcomings in the Certificate Authority system. Subordinate certificates have long been identified as a point of weakness in the CA system. They are typically granted unconstrained power to issue certificates for any domain name. Thus, a leak of one subordinate certificate is seen as equivalent to a leak of authority equivalent to all CAs combined. Worse, subordinate certificates need not be explicitly trusted by the software that authenticates encrypted SSL connections (typically your web browser). They inherit their trust from the explicitly trusted CAs that have been vetted by your browser vendor. Browser vendors have slowly been trying to reign in the practices of CAs that issue subordinate certificates to third parties. For instance, when CA Trustwave admitted that it had been selling subordinate certificates to third parties for the purpose of performing man-in-the-middle attacks, Mozilla made clear that this was unacceptable. That being said, depending on your browser, there may be a couple hundred trusted CAs. Hoping that they all comply with a policy is probably not enough. I have spent the past couple of years trying to convince Mozilla to strengthen their requirements so that CAs must disclose all subordinate certificates that they have issued, so that researchers can better map the risk landscape and so that users can make more informed trust decisions and detect unexpected subordinates. They’re getting closer, but it is taking an awfully long time. Several years ago, security researchers Christopher Soghoian and Sid Stamm described the “compelled certificate creation attack” in which a government would compel a local CA to produce a subordinate certificate that it would then use to conduct mass or targeted man-in-the-middle surveillance on its citizens.
We are justified in indulging in a bit of professional paranoia, given that the Turktrust subordinate certificate in question was controlled by the Turkish government, and that it was used to perform man-in-the-middle attacks. It also happens to be the case that Turktrust satisfied its annual compliance audits by having the Turkish government audit their operations, as opposed to the more common practice of obtaining an audit from a commercial auditing firm (although they claim to have recently obtained a commercial audit, they have yet to publish any documentation of this as far as I can tell). Turktrust has begun to give some answers, but it’s worthwhile to keep probing.
Mozilla revoked trust in one of Turktrust’s three “root” CA certificates, as did Google–but oddly the revoked root is not the certificate that issued the subordinate certificates in question. It is a new root certificate (included in Firefox only in beta releases so far), and it is intended to be used only for issuing higher-standard “extended validation” certificates. It appears that the browsers’ strategy is to provide some mild punishment to Turktrust without disrupting the operation of legitimate sites that have obtained standard SSL certificates from them in the past. Representatives from both browser vendors have stated that it is unclear how they will proceed, and one can imagine that they would restore trust in this root at some point in the future. Is Turktrust’s behavior sufficient that trust in all three of their roots should instead be removed permanently? The facts are still emerging.
Subscribe to:
Posts (Atom)