PCI council formed; revised standard includes app security requirement |
 |
By Colleen Frye, News Writer
08 Sep 2006 | SearchAppSecurity.com |
|
|
The much anticipated update to the Payment Card Industry (PCI) Data Security Standard was announced yesterday by the PCI Security Standards Council, an independent council created by American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International that will manage the standard going forward. The council's first official act was the release of version 1.1 of the PCI standard.
Version 1.1 clarifies existing requirements as well as adds some requirements, but contrary to speculation over the past few months, it does not relax or water down security requirements for merchants and vendors. Specifically, there had been speculation that the encryption requirement would be relaxed and that organizations would have to scan only for SQL injection and cross-site scripting vulnerabilities. Neither proved to be the case.
"There is definitely not a reduction in security," said Seana Pitt, chairperson of the new PCI Security Standards Council and group vice president of global merchant policy and data quality for American Express. "One of the key objectives is addressing emerging threats and finding ways for us to allow key stakeholders to apply the standard more efficiently within business. Some [of the update] has been cleaning up imprecise language and recognizing compensating controls -- there is more than one way to make sure data is secure -- and to give more pathways that merchants can show they can do those things."
|
|
|
|
|
A mandate of source code review for custom Web applications is huge -- it's something every expert will recommend.
Jeremiah Grossman
Founder and CTO, WhiteHat Security Inc.
|
|
|
|
|
|
|
|
|
|
Also of note, she said, is the new requirement under section 6, which is to develop and maintain secure systems and applications. The new 6.6 requirement states that all custom application code must be reviewed for common vulnerabilities by an organization that specializes in application security or there must be a Web application firewall installed in front of Web-facing applications. This requirement will be considered a "best practice" until June 30, 2008, and then it becomes a requirement.
Pitt said with the addition of this best practice, as well as addressing implementation concerns and emerging threats, "we believe we're raising security."
Jeremiah Grossman, founder and CTO of WhiteHat Security Inc. in Santa Clara, Calif., called section 6.6 "probably the most significant change. A mandate of source code review for custom Web applications is huge -- it's something every expert will recommend."
The challenge, though, is the amount of source code out there, he said. The option to install a Web application firewall may be the easier solution, he said. "Customers are still leery about putting [a Web application firewall] in front of a production network because it has the ability to block legitimate traffic," he said.
But Grossman said he has been recommending organizations install the ModSecurity open source Web application firewall. "If the choice is a source code review or a Web application firewall, I think it will be easy for customers to install ModSecurity and call it a day," he said.
Dr. David Taylor, vice president data security strategies at Protegrity Corp. in Stamford, Conn., which sells a Web application firewall, is naturally "pleased about that." Compared with changing development practices to incorporate security, "it turns out a firewall is lot easier to get." However, he added, "if the goal is to postpone everything for as long as possible, I guess people will wait for 2008."
Taylor said postponement was a tactic some organizations were taking with PCI compliance, hoping the update would relax some of the security requirements. "I did see a number of people waiting to implement PCI because they were thinking either the regulations would get easier to comply with or would be relaxed in one way or another."
But "PCI is not getting softer," he said. "People had been telling me they'd been told you're not going to have to encrypt anymore. The nice thing is, 1.1 specified what compensating controls must do and how you determine whether a compensating control is effective or good, but they haven't given people an easy out."
The council's role
While the standard is staying rigorous about security, the process itself is opening up to a wider community -- something those in the security community have said they wanted to see. With the formation of the council, merchants, payment devices and services vendors, processors, financial institutions and others now have the opportunity to participate in the new organization and contribute to the evolution of the standard. All of the five founding members have agreed to incorporate the PCI standard as the technical requirements of each of their data security compliance programs. Enforcement, however, will be left up to the individual credit card brands.
The council's Pitt said she does not anticipate that the five payment brands will vary from or add to the requirements on an individual basis. "My expectation is that the PCI data security standard will be the technical foundation for all brands going forward; each will drive additions through the council. I don't see individual effort happening at this point in time. There is a huge commitment to ensure that standards are well adopted."
As for any vendors that have been certified by the individual brands to provide PCI compliance services, they will be re-contracted by the council when their certification comes due, and the council will maintain a list on its Web site of all certified vendors that will recognized by all five credit card brands, Pitt said.
"The formation of a new committee is pretty interesting," Grossman said. "It makes complete sense that all the brands are working together."
|
|
|
|
