Showing posts with label PCI. Show all posts
Showing posts with label PCI. Show all posts

Thursday, June 25, 2009

Know Your Audience: How Not To Sell CVV2's

The Society of Payment Security Professionals forum is a great resource for PCI compliance discussions. Sadly for user goodcvv_vn, it is not a good place to sell CVV2 codes.

The price list is, however, a great resource for my security talks - and of course, the offer to share free socks is compelling, as seen in the forum post, quoted here:

Sell cvv2 good& cheap....!!! and share free socks


Hello, I'm a new seller, Im from vietnam, I have any friend hacker
my cvv are the best for you

Ccv US is $ 1.5 per ccv (Visa)
Ccv US is $ 2 per ccv (master)
Ccv US is $ 3 per ccv (Amex + Discover)
Ccv UK is $ 4 per ccv (Visa + Master)
Ccv UK is $ 5 per ccv (Amex + swith)
Ccv Ca is $ 6 per ccv (Visa+ Master)
Ccv Ca is $ 9 per ccv (Visa Business + Visa Gold)
Ccv EU is $ 6 per ccv (Visa + Master)
Ccv EU is $ 7 per ccv (Amex + Discover)
Ccv Au is $ 6 per ccv

I can check balance in cvv,balance will be as you like and price agreements
if u buy over 50, I will sell for you good cheap, good price
I only accept payment with LibertyReserve
i will discount my price for u if u are reseller buy everyday or u buy many
all my cvv will be tested before sell, that's sure.
Please contact me: email redacted
on yahoomesenger: IM redacted
The use of LibertyReserve, a Costa Rica based payment processor is also worth noting for those investigating payment card fraud.

Friday, June 5, 2009

Data Breaches, Lawsuits, and Auditors - Oh My!

Wired's Threat Level writer Kim Zetter reports that Savvis is being sued as part of the 2005 CardSystems breach. Zetter notes that this is a legal first, making this an intriguing case to follow. Savvis' role as a Cardholder Information Security Program (CISP) auditor. This predecessor to our broadly adopted and audited PCI-DSS standards was expected to help ensure that a compliant entity was secure.

Additional coverage can be found on various security sites around the net, such as SC Magazine, which observes that the breach occurred almost a full year after the certification - enough time for a multitude of compliance issues to creep into any environment if not carefully maintained and re-assessed.

Zetter also notes that credit card companies are aware that even those companies that have clean audit results are often vulnerable. This creates an interesting scenario - companies are required to meet PCI standards, and pay for certified auditors to assess their systems. Should they then be indemnified against compromises? Where does responsibility for incorrect audits and assessments lie?

Unfortunately, it is rare for organizations to completely meet all of the standard, and exceptions and local accomodations are common - and even when an organization meets all of the standards, they do they can be vulnerable. The PCI-DSS standards are a step forward for credit card processor security, but this lawsuit is likely only the first in a series of lessons the entire industry will learn about auditing and standards compliance.

Monday, February 9, 2009

Grossman's Unanswered Questions

Jeremiah Grossman, one of my favorite web application security bloggers, recently posed a few of his unanswered questions - here's my take on a few of them, but be sure to read the comments thread. Anton Chuvakin's note that "firewall + website = web application firewall" in the minds of some rings true after my own experiences with compliance efforts.

1. Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?
For those not in the know, a QSA is a "Qualified Security Assessor" - a PCI approved assessor. PCI-DSS 6.6 (updated detail) says that you can use any of the following:
1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools
The problem that Grossman points to here is that some vendors will use a vulnerability scanner that doesn't provide deep software analysis capabilities - using Nessus instead of WebInspect, for example. My answer here is a firm "No". The capabilities found in full featured application vulnerability scanning tools are far more advanced than those found in most standard host vulnerability scanners. Vendors like Qualys are expanding their capabilities here, and other vendors are or have already. My answer will likely change as these features become increasingly more capable, but for now unless the QSA explicitly explains it, this doesn't appear to be the right solution.

Does this mean that organizations without internal technical expertise won't take a QSA's analysis at face value? Not at all. One of the major reasons that QSAs exist is because organizations need or want 3rd party assessments, and they trust those assessors to help them meet their PCI requirements.
3. As a result of economic downturn, what notable security projects are being cut from last years budget?
Training is being slowed down, and colleagues at other organizations note that they are cutting major initiatives - SIM/SEM technology, new IDS/IPS deployments, and other major hardware and software purchases are being delayed or are being re-scoped to highly critical areas. They're also getting more push to build internally.

The number of vendor calls, and the aggressiveness of those vendors is also increasing. I'm fielding more cold calls, and we're seeing things like the quick Google AdWord snap-ups following High Tower's demise.

I'm looking at the pullbacks as an opportunity - the frenetic pace of security device and technology deployment over the past few years has resulted in a wealth of existing information that frequently isn't as well leveraged as it could be.
5. Will secure code purchasing standards lead to secure code?
Sadly, no. I've seen some efforts along these lines, but I think that we'll see more success by putting testing tools into the hands of developers, as well as greater organizational maturity - secure code re-use for example.

As penalties for security issues become a more frequent topic of contractual negotations, this may begin to change. I've been advocating such a change in my own organization for a while.