[dbg31415]

> Do you contend that you still need PCI Certification even if you're only using Stripe?

Yes, if you have BOP or other form of liability insurance, one of the questions is frequently, "Are you PCI DSS Compliant?" If your legal team feels comfortable with your self-assessment for certification... sure, go with that. When it comes to your business, I think 3rd Party Audits can be quite helpful.

Here's an example question I pulled from an RFP just yesterday:

http://i.imgur.com/R2WCOvY.png

Here's an example I pulled from another client's liability insurance questionnaire:

http://i.imgur.com/1s7zBkd.png

What do you think sounds better, A or B?

A) "Yes, we are compliant, and verified through self-assessment..."

B) "Yes, we are compliant and verified annually with XYZ Certification Company..."

But look, my main point was that with all of this there are non-technical considerations that play in. One team doesn't have all the answers, it takes a variety of disciplines working together to make a company run. Dismissing people who say PCI compliance is not just a technical issue shouldn't be the automatic response.

EDIT:

Let me follow up with another example... let's say you're the developer of an eCommerce system. You set it up to use Stripe and you've done everything correctly in terms of selecting a PCI Compliant hosting partner, etc.

What happens when customer support decides to, after processing a refund, help the customer re-order something? They take the customer's credit card over the phone, and create a new order for the user using the admin tools of the site... they're being helpful and accelerating the re-order process. But... presto you are no longer just a shop that just uses Stripe. How do we ensure that data is being handled correctly, that our staff haven't written down CCs or haven't stored them somewhere?

3rd Party audits can help a company uncover issues like this. And you, as the developer, don't want the liability of saying, "Yes we filled out the self-assessment and everything was great!" because you don't have visibility into how the tools you built get used after you hand them over to the client.

It's worth reading the actual guidelines for self-assessment if you have time, then you know for yourself if something is BS or not. Note that if you don't fall nicely into one of these categories, you don't qualify for self-assessment. (Check out A-EP for stores that exclusively use Stripe.)

* https://www.pcisecuritystandards.org/documents/SAQ_InstrGuid...

[mgkimsal]

So what can a developer do to their code to prevent someone in another part of a company from taking a phone call and writing down someone's credit card number? "Self assessed" or not, I'm failing to see how this can be prevented (or, more precisely, can be prevented by someone in the software development team). Not allowing certain IPs from entering credit card info at all? That's the only thing I can think of off the top of my head.

[dbg31415]

The other response was good, but yeah to be clear you don't want to go blocking your customer service IPs... that's just going to impede sales / returns / their ability to do their job.

You want to encourage your company as a whole, development and legal and everyone else, to take part in regular 3rd party audits and training around PCI Best Practices.

My point at the start of this was just that it doesn't do any good to dismiss this as "scammy" or think that one team can do this by themselves.

There's no "dev solution" here -- it's gotta be a company solution. (=

[rbobby]

Part of the solution is that the admin functions do not collect credit card details at all. So through the admin site/app a customer service rep can't do an actual purchase.

That won't stop a customer service rep from using the retail site though.

I suppose you could monitor the retail site's log files and throw notifications when a customer service IP makes a purchase. Maybe also throw notifications when a customer's repeat business comes from a different IP (though this could be noisy).

Trying to block customer rep access to the retail site might be pretty tough. You'd need to really lock down a rep's workstation because they could be remoting into their home machine... assuming the rep was out to steal cards. At this level of paranoia I would expect all calls to be "monitored for quality assurance".

Hmm... there's an idea for a call center application addon. Use voice to text and machine learning to identify calls where a credit card number is asked for and/or spoken. This could be pretty easy once the voice to text is right (basically looking for strings of digits, maybe with long pauses between groups or "ok", "got it", "yeah").

[vertex-four]

PCI DSS compliance is a company-wide legal issue and thus needs buy-in from all relevant management and legal teams. Period. Self certification is mostly useful for small companies that might not even have a customer service "department", maybe just one or two people.

[mgkimsal]

Replying to myself

I may have misread the post I was replying to, but the poster seemed to be implicating the developer(s) as being culpable or at-fault for PCI non-compliance if some of these other things happened, which just didn't seem reasonable. That's what I was questioning, and yes, of course PCI compliance (as with other sorts of legal issues and whatnot) really are 'entire-company' issues. Devs can't/shouldn't be blamed if someone violates corp policies.

[pixl97]

Much like the other replies to your comment, it's a whole company issue.

Many companies have had issues where 'customers' (read people committing fraud) come into a retail location and replace equipment with hacked readers. Your company needs to have measures to prevent things like this from occurring. It's not just 'credit card' security any more, it's protection against a number of human and computer equipment attacks.

[rbobby]

A-EP?