I learned that I have no future in media.

In the new PCI 6.6 supplement, the council has given more direction on how to meet the dreaded 6.6 (should be 6.6.6) before the June 30th deadline.  Originally, many thought 6.6 would require full code reviews or a web application firewall.  Then, based on comments from Bob Russo, it looked like a mix of reviews and scanning was in order.

Alas, we were all delighted to find out that the options for 6.6 are simple.

Option 1:

•  Code Review which is subdivided into 4 options:

• Manual code review of application source code
• Proper use of automated source code analyzer (scanning) tools
• Manual web application security vulnerability assessments
• Proper use of automated web application security vulnerability assessment (scanning)
  tools.

• WebApplication Firewall (WAF)

Now with that cleared, here is what I see.  All of the source code assessment tool companies and web application firewall companies are in a panic.  6.6 was their pay day, but now it appears we have an eaiser way to achieve this by running a web application scanner such as Webinspect.

While there is defiantly benefit in source code reviews and WAFs have their place, though disputed by many, performing a review with a scanner is much more cost effective.  At the end of the day, we are in business to make money and must make compromises between security and business. I think we have found that compromise for 6.6.

A quick review basically outlines what we expected. PCI is taking Visa’s PABP program, transitioning it into PCI standards and putting the screws to the application vendors via the merchants.

A quick run down:

• The new requirements apply to 3rd party developed applications that store, process, or transmit cardholder data as part of the authorization or settlement.
• Merchants can only use third party payment applications which are pre-approved or able to pass certain criteria. This basically means, use what is pre-approved and save yourself time. Note: Internally developed payment applications which are not sold or licensed to a third party are not in scope.
• For those applications not on a pre-approved list, the QSA must have a lab to test the application against the PA-DSS standards. PCI outlines new guidelines around testing and the lab requirements.
• The merchants are liable, thus they will affect the vendors compliance through purchasing decisions directed by PCI.

I applauded PCI for sending this out and providing a comment sheet so that the standards can be improved before going live. Over all most of what I have seen so far I expected, let’s just wait to see what the final release looks like.

Black Box Testing

Like all things in life, black box testing has its ups and downs. Through this testing method, the tester focuses on portions of the application which the user would interact with. It is not possible, in standard cases, to access portions of the internal code since this is a black box test, duh. This method focuses on attacking the application and thus simulates what an attacker would due, thus the one benefit. The other main benefit is cost as this method is normally the least expensive approach.

White Box Testing

White box testing, or source code analysis, is arguably the most comprehensive testing method. This method involves analyzing lines of source code either through manual review, automated tools, or most commonly a mix of both. While this method seems to be the best since it allows the tester to review the source of the problem, pun intended, it can be costly and timely. In large applications this has another downside. Testers may focus too much time on code which old, left over, or has never been used thus noting defects in code which should be removed instead of fixed. This adds to the cost and time of the engagement. The major up side is that in the right scenario this can really benefit an organization.

Grey Box Testing

Grey box is a mix of white and black box testing. The test normally has some knowledge of the application’s inner workings which is used to build test cases. These test cases are then performed in a black box method. This makes the black box testing more efficient and generally more valuable. This method is typically preferred over straight black box testing when possible, though is not a replacement for source code analysis.

Binary Analysis

Binary analysis is a slightly different approach. While it is similar in theory to black box testing, its main goal is to obtain the application binary, reverse engineer the binary, and find defects. This method differs from black box testing in one significant way; the binary is provided to the tester and not simply tested from a remote system.

Each of these methods has its own benefits and each has its pitfalls. In the end, I believe we will see a mix of these testing methods coming together to allow for better testing. Black box testing takes into account system configurations which is important in application testing, white box gets the tester to the root of the problem and allows the tester to fully understand what is happening, grey box mixes these to methods. I think we will evolve and redefine the grey box testing to fully incorporate white and black box methods and then rename it to something simple like application security analysis.

We need better source code analysis methods than we currently have, we need better black box testing methods, and finally we need better integration with the developer’s IDE. Once we have better tools and integration with all, we will finally be able to mature this process and the industry.

“Research indicates that if a threat hasn’t happened in our own cozy community, the human mind actually softens its threat assessment. Or worse, makes us cast a blind eye. “

I will not disect the article as I think the conncetion between wild fire and information security is an easy one to make. I suggest reading the article in full and it may help rationalize what seems to be illrational thinking.