PCI Security Standards Council to address application security requirements |
 |
By Colleen Frye, News Writer
28 Aug 2007 | SearchSoftwareQuality.com |
|
|
Application security requirements in the Payment Card Industry (PCI) Data Security Standard (DSS) will be up for discussion when the PCI Security Standards Council meets next month for its first community meeting.
|
|
|
|
|
PCI is often referred to as prescriptive, but customers are saying, 'One auditor told me this, and another that, so what's the real answer?'
Diana Kelley
VP and service director, The Burton Group
|
|
|
|
|
|
|
|
|
|
Robert M. Russo, general manager of the PCI Security Standards Council, said during a recent telebriefing hosted by analyst firm The Burton Group that the council expects to discuss feedback and clarifications on version 1.1, including issues specific to application security. Feedback from the community, which is open to all PCI Security Standards Council participating organizations, qualified security assessors (QSAs) and approved scanning vendors, is in the process of being compiled.
As part of the ongoing work on the standard, Roberts said the council is looking closely at the Open Web Application Security Project (OWASP), and one session at the community meeting will include OWASP representation on the panel.
PCI DSS 1.1 consists of 12 security requirements and various subrequirements. Although Roberts could not speak to specific revisions and clarifications prior to the meeting, he expects application-level requirements to be addressed at September's meeting. Those requirements fall under Requirement 6: Develop and maintain secure systems and applications. Specifically, he expects Requirement 6.6 to be discussed: Ensure that all Web-facing applications are protected against known attacks. The requirement, which is considered a best practice until June 2008 when it becomes a requirement, says organizations may use one of two methods of protection: a code review or an application-layer firewall.
Roberts said he expects the feedback to provide insight on code review versus application firewalls. Other related feedback and questions have revolved around the role of the QSAs, he said, such as should the same QSA also do the code review or should organizations buy a tool to do a code review? Or would an application firewall be enough?
Roberts also said he expects some clarity to be brought to the issue of an application-layer firewall: "Is that an application-aware firewall or an actual application firewall that sits in front of the application?"
Rules for security patches
Ed Moyle, a certified PCI QSA and manager at CTG, an IT services and consulting company in Buffalo, N.Y., said he expects Requirement 6.1 regarding security patches to be discussed as well. In particular, he expects the council to talk about the issue of installing patches within 30 days. For example, he said, for some organizations, 30 days may not be enough time to push the patch all the way through their processes. Another question is, would putting host-based intrusion prevention software (HIPS) in place qualify?
"From the standpoint of the assessor, our mandate is to look at the intent and rigor, and that any compensating control put in place meets that rigor," Moyle said. "If you can't meet 30 days, I'd be looking for something that meets the intent. I'd look for HIPS or other interim protection, but with a strategy in place to meet the intent of the requirement."
According to Diana Kelley, vice president and service director at Burton group and moderator of the telebriefing, organizations that start down the road to compliance may initially feel meeting the 12 requirements is not that difficult. "But when they dive into the subrequirements and the security audit procedure around those requirements, they're finding out some nits," she said. "Assessors are not always agreeing. PCI is often referred to as prescriptive, but customers are saying, 'One auditor told me this, and another that, so what's the real answer?'"
Kelley said organizations Burton has communicated with express concern about a 2.0 version of the standard -- If requirements get tighter, what can they do to prepare? Or if the requirements loosen up, what compensating controls will be allowed?
From the trenches, Kelley said organizations are finding some things that are working in terms of meeting the requirements: "Delete what you don't need. Card numbers are being stored because they could be stored. If you don't need to store them after the authorization period, don't." Also, "go ahead and zone [limit the size and scope of the audit surface]. It's working for a lot of organizations."
Finally, she said, "Take a close look at your applications. Look at the history of credit card violations -- often an application is involved."
With respect to any revisions of the standard, Roberts said it remains to be determined if the next version will be 2.0 or a smaller release such as 1.2. But there are a few guidelines the council is looking to follow going forward. First is to bring clarity and consistency to the DSS or any other standard that emerges from the council. The second is "to make sure we stay flexible, like with compensating controls. This is not only regarding data encryption, but allowing anybody to submit anything for a compensating control. If there is more than one way to skin a cat, we'll give you an opportunity if you found a good way to do so."
Overall, Roberts said he has seen an up tick in organizations working toward PCI compliance.
"I think it's a bit deceiving regarding numbers with respect to level 1 merchants," he said. "In some instances this is not as easy as flipping a switch and becoming compliant. Level 1 merchants are running legacy systems. It's easier to build security in rather than retrofit if. But if level 1 merchants aren't already compliant, they are well on their way. They have plans and budgets in place. It could take a couple of years for them to become fully compliant."
Notably, Roberts said the types of questions the council receives have evolved from "Why do I have to do this?" to "How can I do this, and how can I do it faster?"
|
|
|
|
