Requirement 6.6 … if you're a merchant or service provider processing credit card transactions, you know what this is, and you know the deadline is looming.
On June 30, Requirement 6.6 of the Payment Card Industry (PCI) Data Security Standard (DSS) -- whose goal is to ensure that Web-facing applications are protected against known attacks by either completing a code <http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci1153150 ,00.html> review or installing a Web <http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci 1163145,00.html> application firewall (WAF) -- moves from a best practice to a requirement. In April, the PCI Security Standards Council, which oversees the standard, issued clarifications to 6.6, spelling out more clearly what a WAF needs to do, while at the same time breaking out four alternatives for doing a code review. Security professionals say the clarifications are a move in the right direction, but warn that as with any standard, there are limitations, and companies will still face some hurdles to meet the deadline if they are not already well on their way. Greg Reber, president and CEO of information security company ASTech Consulting in San Francisco, called the clarifications "a good step. It's getting more clear without being too prescriptive, which companies don't like." Michael Gavin, a security strategist at Security Innovation in Wilmington, Mass., added that it's good that the clarification document came out before the deadline. "Now [merchants] and QSAs [Qualified Security Assessors] have a good example of what has to happen, what exactly is a Web app firewall and what will satisfy 6.6, and how extensive the code review has to be. None of this was discussed before." However, he added, "I suspect companies will be scrambling once their annual on-site audit comes around and they have to do something for 6.6." What companies will have to do to be in compliance with Requirement 6. 6 is implement one of two options to protect Web applications. The first is a code review, and there are now four alternatives for doing a code review: * Manual review of application source code * Proper use of automated source code analyzer tools (scanners) * Manual web application security vulnerability assessments * Proper use of automated Web application security vulnerability assessment tools (scanners) The second option is to deploy a WAF positioned between a Web application and a client end point that performs the functions detailed in the clarifications. "There are all kinds of ways to find vulnerabilities in Web sites. This gives companies flexibility," said Jeremiah Grossman, chief technology officer at WhiteHat Security in Santa Clara, Calif. However, he added, "It's up in the air which testing process is the best and the most cost-effective; people like white box testing because it provides a set of values, and black box provides a set of values." (See <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1246398,0 0.html> "Web application testing: The difference between black, gray and white box testing") In terms of taking one of the manual options, what is still ambiguous is how a "qualified person" to do the review is defined, Grossman said. "But at least it's giving companies the options of different types of testing." A look at code review Among the code review options, ASTech Consulting's Reber said there is a "huge delta in the understanding of risk present." For example, he said, looking at the first two alternatives, a manual code review vs. an automated source code scan, "automated tools today do not find all the vulnerabilities a manual assessment does. You will get a much better understanding with a manual assessment." And, he said, in terms of the third and fourth alternative, a manual vs. an automated application security vulnerability assessment, "we don't believe a vulnerability assessment is an accurate comparison with code analysis. These are not actually looking at source code, so saying it's a code review is a stretch." More information on Web application security Web <http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci13101 23,00.html> application security testing basics <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1217076, 00.html> Web <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1217076,0 0.html> app security tools and products find source code vulnerabilities What <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1264497,0 0.html> to expect of a third-party Web application security tester Gavin of Security Innovation agrees: "They really should have reworded the requirement now that they've changed the options." Barry Johnson, a PCI QSA and vice president of risk mitigation at igxglobal, a provider of security solutions and services in Rocky Hill, Conn., recommends a source code review to his clients. "It's what you should be doing if you develop your own code. It allows you to see everything, how data flows through the program. You find weak points you couldn't find with an assessment," he said. On the other hand, Johnson said, a vulnerability assessment, like any type of test, "is a good thing." The vulnerability assessment alternative "allows them a more cost-effective way of addressing risk. A source code review from the outside can be expensive. If you do a vulnerability assessment because you can more afford it, in that sense it's a good thing. It allows them to help meet the requirement and helps address risk." Bob Russo, general manager of the PCI Security Standards Council, said the alternatives give companies options. "I come from a code review background, and in my opinion the best thing is to make sure you train people writing code how to write secure code," he said. "Basically a code review is probably the most thorough, but it's also the most expensive. We needed an alternative. Software is getting better and better, and there are two ways to skin this cat. A Web application firewall is a good alternative to a full-blown code review." Russo continued, "If you do a vulnerability assessment, they're checking for the most egregious things. That's not to say the code is perfect, but vulnerability scans give you the known vulnerabilities. We had to give them the option to [meet the requirement] a couple different ways. Some people will go the extra yard and do code reviews to the letter, but some don't have the resources, and a [vulnerability] scan is good enough. If they're doing a scan, we feel confident a scan will pick up the holes." Web application firewalls For organizations that choose a WAF to meet Requirement 6.6, the clarifications detail what it needs to do, but Gavin cautions that many will have "a bit of a rude awakening." "There will be some sticker shock, and they'll need to figure out how to deploy it in their environment," he said. "The way you deploy a WAF is different than a network firewall; you want to have it as close to the application server/the Web server as possible, so you might have to buy more than one, and that can be expensive. There are open source options." Johnson added that the challenge of implementing a WAF is "finding one that when properly configured enforces all the PCI requirements and doesn't break their application." "Sometimes when everything is turned on, you'll find the application is dynamic in nature and ceases to work," he said. "I have seen where companies end up having to disable certain WAF features if the application ceases to work, but if you disable some features you may not be PCI-compliant anymore. There's never an easy answer." And the QSAs can't give organizations an easy answer, either, as they're not allowed to validate products. "We do have merchants that want to know if this WAF 'will do it for me.' Only when we do the assessment can we tell them if it's meeting the requirements. There are so many ways to meet a requirement; there's no clear answer," Johnson said. Meeting the deadline In terms of meeting the June 30 deadline, security professionals say it is a mixed bag. Dale Masi, a PCI QSA and senior technical consultant at Forsythe Solutions Group in Skokie, Ill., is in the process of working with two clients on PCI compliance. "Between these clients and others, some are under the gun for the deadline; others are looking toward future needs," he said. "For any client we've dealt with, security is a top priority. They're putting their hands around this compliance initiative coupled with other compliance initiatives, so there are new reporting requirements and the implementation of new devices and solutions." Security Innovation's Gavin said he has been pleasantly surprised to see that most customers are more concerned with security and getting PCI compliance as a byproduct. "Naturally some want to do it the cheapest, easiest way possible, and for those companies we try to educate them to what the purpose is," he said. "If they're going for a compliance 'checkmark,' they will have one big task every year. But if they're managing from a risk perspective, they'll have ongoing costs and projects, but over time the cost goes down considerably." The time frame for moving Requirement 6.6 from a best practice to a requirement was 18 months, which the PCI Council's Russo said was sufficient. "I haven't heard griping or any issues. If they're Level One [merchants with over 6 million transactions a year], they're showing their QSAs [that they're compliant] or they're self-assessing, showing the brands they are compliant," he said. Masi agrees that 18 months is good lead time. "There are clients that will be behind the gun -- either they looked at it at the last minute or had other business priorities -- and this is where this initiative fell. It's a client condition more than an unreasonable requirement, and hopefully for most it's not an issue." According to what Johnson has seen, the large companies that are developing in-house applications have it under control. "That's part of the reason as a QSA we brought it to the forefront in the beginning. We knew what was coming," he said. "The clarification made things easier. For a lot of the large customers, it wasn't something that took them off-guard. The smaller clients that just went out and purchased pieces of software, they're struggling." Limitations/challenges There are limitations to any standard, of course, and some technical challenges. "For a lot of companies, there's too much source code out there," Grossman said. "The other thing they'll have to figure out is which environment you have to test, whether it's development or production. In the course of doing my work, in the staging vs. production environment the vulnerabilities almost never match. You could have a clean staging environment and have a production environment riddled with vulnerabilities." Another issue is what organizations do with the information they get about vulnerabilities. "You can do a secure code review and not do anything with the output, which would be obviously a poor practice," Masi said. "You could put in a WAF and install it and you still don't meet the requirement. You need to manage that and evaluate it on an ongoing basis. It's more a matter of practice and management when those options are in place as to how well they perform." Also, Masi said, "This initiative is focused on payment card applications, so you could have an organization that has other business going on in other network operations, like back office. This [standard] is not used to look at an organization in a holistic manner, so it's just looking at components related to PCI." Johnson said he doesn't think the DSS standards by themselves are helpful. "They give good guidance, but they don't require validation all up and down the line. Merchants can do a self-assessment questionnaire. My gripe is it's not enforced to every merchant, only at Level One providers," he said. ASTech Consulting's security practice manager Carl Schwarcz added: "The constant struggle in this industry is people wanting to check a box, so 'I'm doing all that's required to do and it's all I have to think about.' I look at PCI as being a minimum step. I know from our practice we find serious vulnerabilities in applications that wouldn't have been discovered in PCI reviews." The best approach, many agree, would be a layered security solution that includes code review, vulnerability assessment and a WAF, but organizations have to be practical, too. "To be really safe, if you've got the time and money, the more layers the better," Russo said. "But it may be overkill. It has to be what merchants can spend and have the time to do." Schwarcz said, "I would hope companies would look at PCI compliance as one line item and one major objective in the security plan for their company. The scary part must be some companies are saying security equals PCI. To me they're in high risk." The PCI DSS, Masi concluded, "gives organizations key components and the first steps in creating a secure architecture and business model they can operate on, and provides their clients with a comfort level to do business with them. I would say we're moving in the right direction, but security will always be a moving target." [Ph4nt0m] <http://www.ph4nt0m.org/> [Ph4nt0m Security Team] <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] Email: [EMAIL PROTECTED] PingMe: <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wu hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> === V3ry G00d, V3ry Str0ng === === Ultim4te H4cking === === XPLOITZ ! === === #_# === #If you brave,there is nothing you cannot achieve.# --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
<<inline: image002.gif>>
<<inline: image003.gif>>
<<inline: image004.gif>>
