Ask HN: Should I report my main competitor for PCI Violations?
41 comments
I guess I'm the odd one out on this, but why not send your competitor an email and let him know what he's doing is risky and dangerous. Perhaps he doesn't know? Perhaps he had a developer who told him everything was fine, and a friendly, across-the-aisle approach could help things.
As you said, you'd probably put him out of business, and regardless if that's your competitor or not, it's still a human being with a life that will be ruined.
As icebraining mentioned earlier, it's not illegal to not be in PCI compliance, just really, really dumb.
As you said, you'd probably put him out of business, and regardless if that's your competitor or not, it's still a human being with a life that will be ruined.
As icebraining mentioned earlier, it's not illegal to not be in PCI compliance, just really, really dumb.
This is the most interesting answer. On one hand business is business and if a competitor is truly doing something that is risking the livelihood of it's customers, that's not good and they should have a right to know and subscribe to a better service. On the other hand, he is human and might have had a developer that was clueless, etc.
His reply would be key to determining which is true. If he purposefully did it to save costs, not caring, etc. then you have good reason to publicly call him out on it. If he truly was clueless and this is a big oh shit moment to him then you have a couple options you didn't otherwise have. If he doesn't have a big dev team (and if he does they seem incompetent) he might be willing to sell instead of spend the money to fix everything. There might also be some other creative solutions that would be beneficial for you rather than attacking it head on publicly.
His reply would be key to determining which is true. If he purposefully did it to save costs, not caring, etc. then you have good reason to publicly call him out on it. If he truly was clueless and this is a big oh shit moment to him then you have a couple options you didn't otherwise have. If he doesn't have a big dev team (and if he does they seem incompetent) he might be willing to sell instead of spend the money to fix everything. There might also be some other creative solutions that would be beneficial for you rather than attacking it head on publicly.
On the other hand, if someone doesn't follow such an obvious practice, isn't there a good probability that they've fucked up in many other less visible ways? What's more likely - that the business owner will have a flash of realization and order a full security analysis of his software, or simply patch this problem (by hiding the CC) and leave the others unfixed (e.g. keep the numbers unencrypted)?
And in any case, would a report really be likely to put him out of businesses for just this mistake? That doesn't seem in the interest of the people doing the analysis.
And in any case, would a report really be likely to put him out of businesses for just this mistake? That doesn't seem in the interest of the people doing the analysis.
The former customer and her/his bank have an honest interest in ensuring PCI compliance. Have the customer tell her/his bank/CC company, and have the customer optionally contact the business. In my experience, when I reported my landlord's management company for clear text passwords, my bank (BofA) followed up and the company rolled out PCI-compliant passwords in a couple months.
This might be the nice thing to do, but anything that points back to him being the source of the complaint may not be best for him in the long run.
Why not? If the competitor decides not to take his advice, and he then reports him for violating PCI, he can say, "Hey look, i reached out via email to him and tried to help, he blew me off/didn't fix anything, so I then took steps to protect his customers, since he wasn't."
It's about retaliation and legal issues. The guy could easily retaliate with a smear campaign or even take legal action saying he was "hacking" or doing "espionage".
Whistleblowing often has negative consequences for the whistleblower.
Whistleblowing often has negative consequences for the whistleblower.
This is what I'd do for an even more subtle reason. Wrecking his business this way could poison your own well of prospects. The customers of his that you could win just by being better might abandon your whole market segment with a "they're all crooks and incompetents... we only buy from IBM from now on" type attitude once they learn of a bungle this big.
Why would it put him out of business? Is there no way to clean everything up and get back into compliance? There have got to be PCI compliance strike team consulting companies that you can hire to come in and rapidly fix the problem.
[deleted](1)
Anonymously! Don't make yourself a target!
This is the most important take-away here. Possibly communicate via a lawyer, whether you are giving a friendly heads-up or otherwise. This type of thing could be construed into conspiracy.
Giga-up-vote. It's too easy to slip up on security hygiene and either lose a jobs, customers, investors, reputation &| be sued. There's just too many liabilities and it's hard to pull off without being (legally) interpreted as a threat.
It is laudable to Do The Right Thing(TM), but the personal cost is likely nonzero sum.
Be aware, tread carefully, CYA.
It is laudable to Do The Right Thing(TM), but the personal cost is likely nonzero sum.
Be aware, tread carefully, CYA.
[deleted]
[deleted]
I would go for a multi-stage approach here:
- first let them know you know, and that you'd like for this to be handled in the best interest of the users (that's who you're doing this for, right?)
- then, depending on the response you have several options:
- If they stonewall, alert the public
- If they respond, figure out what a reasonable timeframe should be for them to become compliant
- Then give them that much time and review the new situation
- If they're still not compliant but have made progress review the situation from the new vantage point
- If they have not made meaningful progress, alert the public.
Don't let this 'opportunity' get the better of you in the ethics department, what goes around comes around and since you're doing your utmost to be anonymous here be aware that you too might have a skeleton or two in your closet and making enemies with nothing to lose might not be in your advantage.
On the other hand: building a bridge for a competitor to walk over when they were vulnerable might place you well some years down the line when that founder is looking for succession.
As for the whole PCI compliance thing: depending on where this all happens in the chain the company might be lying about them being PCI compliant or their auditors have messed up, either way nobody appointed you judge, jury and executioner so tread with some care, the whole thing might backfire in some unexpected and spectacular way if it turns out you were mistaken.
- first let them know you know, and that you'd like for this to be handled in the best interest of the users (that's who you're doing this for, right?)
- then, depending on the response you have several options:
- If they stonewall, alert the public
- If they respond, figure out what a reasonable timeframe should be for them to become compliant
- Then give them that much time and review the new situation
- If they're still not compliant but have made progress review the situation from the new vantage point
- If they have not made meaningful progress, alert the public.
Don't let this 'opportunity' get the better of you in the ethics department, what goes around comes around and since you're doing your utmost to be anonymous here be aware that you too might have a skeleton or two in your closet and making enemies with nothing to lose might not be in your advantage.
On the other hand: building a bridge for a competitor to walk over when they were vulnerable might place you well some years down the line when that founder is looking for succession.
As for the whole PCI compliance thing: depending on where this all happens in the chain the company might be lying about them being PCI compliant or their auditors have messed up, either way nobody appointed you judge, jury and executioner so tread with some care, the whole thing might backfire in some unexpected and spectacular way if it turns out you were mistaken.
I wouldn't set myself up as a judge. How do you know what a reasonable time-frame is, or meaningful progress?
I'd report it and be done with it. Minimal drama and involvement. Alert the public as a very last resort, if the PCI folks are uninterested (and I guarantee you, they will be interested).
I'd report it and be done with it. Minimal drama and involvement. Alert the public as a very last resort, if the PCI folks are uninterested (and I guarantee you, they will be interested).
Overall I like this approach. If this is an honest oversight and they take actions to rectify it then that is the best. If, on the other hand, they ignore it then I would let the public and everyone else know because there are a bunch of other people that are at risk.
This gets worse when bank accounts are involved because the protections for businesses and consumers are next to nothing if your information is leaked out from a legal perspective and there are many instances of banks not backing up their customers.
We ended up ending a consulting engagement because a client had some big holes in their account security for bank accounts and had no interest in rectifying that. Our problem with that was twofold. First, the customers our former clients had no idea that there was an issue and second, if a breach did occur it could have put our clients customers out of business. There are stories about that happening.
I have personally run across way too many business that are interested in making money, even if that is at the expense of others with severe consequences for those actions.
This gets worse when bank accounts are involved because the protections for businesses and consumers are next to nothing if your information is leaked out from a legal perspective and there are many instances of banks not backing up their customers.
We ended up ending a consulting engagement because a client had some big holes in their account security for bank accounts and had no interest in rectifying that. Our problem with that was twofold. First, the customers our former clients had no idea that there was an issue and second, if a breach did occur it could have put our clients customers out of business. There are stories about that happening.
I have personally run across way too many business that are interested in making money, even if that is at the expense of others with severe consequences for those actions.
Disclaimer: I choose to treat people the way I would like to be treated.
My $0.02: maybe this is just one way your competitor is inept at running their business. I'd say the probability is very high of that. An overwhelmed founder IMO may be a sweet acquisition target. If he knows he is in over his head, maybe he would be happy to sell you his company for terms you can accept. You'll get all the customers, and you'll also know those customers are in your good care.
If you whack him upside the head with a report to Visa, MC, etc. he'll fix it and continue to be ignorant or negligent in all the other ways he is failing to adequately serve his customer base.
Lastly, and please know I am not accusing you of a nefarious plot here. But anyone reading this will see the potential prize of acquiring a competitor's client base. I want to dispel the myth that a report would be a fatal blow to his company that would result in your company ending up with all his customers. His merchant bank who is really on the hook for his PCI compliance will not terminate his account over a first offense. They will instead make even more money off him by imposing remediation consulting. And if those expenses were to put him out of business, there would still be an acquisition cost in reaching his customers, letting them know that your company exists and selling them on your solution.
My general approach to life: I do my best to limit my actions to those that will enhance or maintain the quality of my reflection in the mirror.
My $0.02: maybe this is just one way your competitor is inept at running their business. I'd say the probability is very high of that. An overwhelmed founder IMO may be a sweet acquisition target. If he knows he is in over his head, maybe he would be happy to sell you his company for terms you can accept. You'll get all the customers, and you'll also know those customers are in your good care.
If you whack him upside the head with a report to Visa, MC, etc. he'll fix it and continue to be ignorant or negligent in all the other ways he is failing to adequately serve his customer base.
Lastly, and please know I am not accusing you of a nefarious plot here. But anyone reading this will see the potential prize of acquiring a competitor's client base. I want to dispel the myth that a report would be a fatal blow to his company that would result in your company ending up with all his customers. His merchant bank who is really on the hook for his PCI compliance will not terminate his account over a first offense. They will instead make even more money off him by imposing remediation consulting. And if those expenses were to put him out of business, there would still be an acquisition cost in reaching his customers, letting them know that your company exists and selling them on your solution.
My general approach to life: I do my best to limit my actions to those that will enhance or maintain the quality of my reflection in the mirror.
Most def. Modified Golden rule: "Treat others as they wish to be treated" Some people wish to be treated different than I would, so it might be worth anticipating their expectations.
Meta: http://inewsdesign.com/2012/11/21/richard-bransons-tip-why-y...
Meta: http://inewsdesign.com/2012/11/21/richard-bransons-tip-why-y...
Yes you should. You are following the rules and no doubt at a cost.
You should report him for the same reason that you should report a competitor that is dumping toxic waste in a stream.
They are externalizing costs to society as a whole to maximize their gain.
There is no malice is demanding that everyone respect the law that safeguards us all.
If the competitor does not wish to follow the law then they can move to a locale that does not have that law.
You should report him for the same reason that you should report a competitor that is dumping toxic waste in a stream.
They are externalizing costs to society as a whole to maximize their gain.
There is no malice is demanding that everyone respect the law that safeguards us all.
If the competitor does not wish to follow the law then they can move to a locale that does not have that law.
PCI is not a law, it's an industry standard. Only a couple of states legally mandate compliance to PCI DSS.
I agree OP should report them, though.
I agree OP should report them, though.
This is true, but if the competitor is advertising PCI compliance and is not providing that, their consumers have a right to know that they are not getting what they paid for.
He would lose his ability to process credit cards, possibly having bank accounts closed etc.
Immediately? Wouldn't they give them a "second chance" to implement the necessary changes?
I think it's a dick move. It's like calling the cops because your neighbor is smoking pot in their garage. The activity isn't harming you, it only "harms" the people with a relationship with the company. If it were me, I'd likely use the competitor's lack of PCI compliance as a tool for my own marketing -- I wouldn't even use the competitor's name, but do something like "Unlike many of our competitors <my_awesome_product> is fully PCI compliant because we care about your security." Turn the "weakness" of the competitor into your strength. But reporting him to the authorities? That's very Stasi-esque.
Unless a law is being broken AND it's creating an unsafe situation for your customers or your company, leave it alone. In my opinion it's a classless move to go after your competitors in that fashion. Beat them with a better product. In this case, a "better" product would seem to be one with PCI compliance.
As far as the "toxic waste" analogy -- I've never heard of anyone getting cancer and dying from a lack of PCI compliance. In fact, there are likely more important things to worry about than PCI compliance -- Target and all of the other high profile retailers that were credit-card hacked -- they were all allegedly PCI compliant, yet it still didn't do much good. I'm not hear to debate the value of PCI compliance -- if it's a requirement of your business, then obviously you have to do it. But I am debating the ethics of reporting a competitor for an activity that is NOT illegal, nor is it directly harming your customers or your business.
Unless a law is being broken AND it's creating an unsafe situation for your customers or your company, leave it alone. In my opinion it's a classless move to go after your competitors in that fashion. Beat them with a better product. In this case, a "better" product would seem to be one with PCI compliance.
As far as the "toxic waste" analogy -- I've never heard of anyone getting cancer and dying from a lack of PCI compliance. In fact, there are likely more important things to worry about than PCI compliance -- Target and all of the other high profile retailers that were credit-card hacked -- they were all allegedly PCI compliant, yet it still didn't do much good. I'm not hear to debate the value of PCI compliance -- if it's a requirement of your business, then obviously you have to do it. But I am debating the ethics of reporting a competitor for an activity that is NOT illegal, nor is it directly harming your customers or your business.
> Target and all of the other high profile retailers that were credit-card hacked -- they were all allegedly PCI compliant, yet it still didn't do much good.
How do you conclude that it didn't do much good? The Target breach involved installing malware on the point-of-sale terminals to grab the data as the customer was paying.
As far as I know, the attackers didn't get to the stored credit card data. I suspect that they didn't get to that data in large part because Target was mostly in PCI compliance, meaning that the stored data was encrypted, on database servers isolated from the databases not involved in payment processing, on separate networks with strong access restrictions.
If Target had been treating PCI the way OP's competitor is, the Target breach could have been much much much worse.
> But I am debating the ethics of reporting a competitor for an activity that is NOT illegal, nor is it directly harming your customers or your business.
For a small business that is doing its own credit card storage, PCI compliance costs can be significant. They can easily double or triple the number of boxes you need at the data center.
The competitor is saving a lot of money by completely ignoring credit card security, which gives him an unfair advantage over OP. I'd consider that sufficient harm to OP to justify taking action.
How do you conclude that it didn't do much good? The Target breach involved installing malware on the point-of-sale terminals to grab the data as the customer was paying.
As far as I know, the attackers didn't get to the stored credit card data. I suspect that they didn't get to that data in large part because Target was mostly in PCI compliance, meaning that the stored data was encrypted, on database servers isolated from the databases not involved in payment processing, on separate networks with strong access restrictions.
If Target had been treating PCI the way OP's competitor is, the Target breach could have been much much much worse.
> But I am debating the ethics of reporting a competitor for an activity that is NOT illegal, nor is it directly harming your customers or your business.
For a small business that is doing its own credit card storage, PCI compliance costs can be significant. They can easily double or triple the number of boxes you need at the data center.
The competitor is saving a lot of money by completely ignoring credit card security, which gives him an unfair advantage over OP. I'd consider that sufficient harm to OP to justify taking action.
Your underlying assumption is that they are doing this to save costs or that there is malice involved. I see no evidence of that, merely either incompetence or a company struggling to get with the times or built at a time when this stuff wasn't so much on the radar as it is today.
That happens a lot and there are ways to deal with it, ratting out your competitors to authorities with silent hopes of crippling them and taking their business in the name of protecting the consumer is bad form at best and will come back to bite you hard at worst.
That happens a lot and there are ways to deal with it, ratting out your competitors to authorities with silent hopes of crippling them and taking their business in the name of protecting the consumer is bad form at best and will come back to bite you hard at worst.
I don't think I made such an assumption. He's saving money, regardless of whether ignoring credit card security was an intentional money saving move, or merely a happy side effect of ignorance or incompetent.
The person I was responding to was taking the position that you should not take against against someone if they are not harming you. That money saving, regardless of how it came about, harms OP's business, and so justifies action.
Note I didn't say the action should be calling authorities. Contacting the competitor and letting him know there is a problem would be action, too.
The person I was responding to was taking the position that you should not take against against someone if they are not harming you. That money saving, regardless of how it came about, harms OP's business, and so justifies action.
Note I didn't say the action should be calling authorities. Contacting the competitor and letting him know there is a problem would be action, too.
I concur. I once wrote code (happily long since retired) that stored credit card numbers unencrypted.
It wasn't about cost cutting. It was about me being young and foolish (and, looking back, I'm not sure it's even the stupidest mistake I've deployed to production in my career, but I'm not sure I want to admit to the other candidates just now :).
It wasn't about cost cutting. It was about me being young and foolish (and, looking back, I'm not sure it's even the stupidest mistake I've deployed to production in my career, but I'm not sure I want to admit to the other candidates just now :).
Encrypted card storage is just 1 of 12 PCI DSS security controls.
Also: if you want to delve into counterfactuals, consider what most PCI-compliant encrypted card storage schemes look like. Design a straw-man system yourself. You'll see the problem within minutes of starting. Remember that any cryptographic engineering that requires even a minute's worth of 'tzs cleverness is probably utterly beyond the raw capability of a line-of-business programmer at a major retail chain.
To the parent commenter's point, it's worth making a list of the 5 largest credit card breaches of the last 5 years and noting who provided their PCI attestation; you may find the result interesting.
Also: if you want to delve into counterfactuals, consider what most PCI-compliant encrypted card storage schemes look like. Design a straw-man system yourself. You'll see the problem within minutes of starting. Remember that any cryptographic engineering that requires even a minute's worth of 'tzs cleverness is probably utterly beyond the raw capability of a line-of-business programmer at a major retail chain.
To the parent commenter's point, it's worth making a list of the 5 largest credit card breaches of the last 5 years and noting who provided their PCI attestation; you may find the result interesting.
What most struck me about PCI compliance is how far and how wide its tentacles ended up reaching beyond the obvious places.
For instance, suppose you allow orders over the telephone. A customer can call, talk to a salesperson, and then place an order. The customer will read their credit card information over the phone and the salesperson will enter it into the ordering system.
If your phone system is a VOIP system, congratulations! It's in scope for PCI! Since you probably don't want to have to deal with PCI for every phone in the company, you'll probably end up having to segment your system, so you can restrict sales calls to one segment.
If you are recording some sales calls so that managers can review them for training purposes, you either have to find a way to not record the parts of calls where credit card numbers are read, or you have to treat the recording as sensitive cardholder data and encrypt it. You might think you could just encrypt all the recordings and be done with it. Sadly, that's not good enough, because of the CSC code. You are not allowed to store the CSC code even if you do encrypt it.
Some people implement a system whereby the salesperson can press a button when the customer is about the give sensitive information, and that pauses recording for a few seconds. From what I've read, this is NOT sufficient for PCI compliance.
There are some approaches (aside from giving up on recording) that appear to be acceptable.
1. There is a system called CallGuard [1]. You integrate this with your phone system and your order entry system. When it is time for the caller to enter their card number and CSC, they do so with their phone keypad instead of by voice. CallGuard blocks the touch tones from the recording, interprets them, and enters them into your order system.
2. You can make it so that when a salesperson brings up the card number and CSC entry form, that automatically pauses recording until the form is submitted.
3. You can temporarily transfer the call to an interactive voice response system that gets the numbers and puts them in your order form, and then transfers the customer back to you.
Next up--email! A customer's recurring payment fails because they did not update their account when they got a new card. Your system sends them an email. The customer wants to update their card in response. Some will try to do this by email. They will fire of an email to your support address that tells you they have a new card and includes the number.
Now you've got a credit card number stored in the mailboxes of everyone who receives copies of support requests, and you'll have to do something about this. At least with a credit card in a mailbox, it's likely to be in a fairly standard and documented format.
If your company is big enough to have outgrown handling support requests by having a "support" mailbox that all your support people read, you probably have some kind of help desk system, and that's where that customer email with the credit card number ends up. So now you find yourself digging around in some big PHP codebase, and poking around a MySQL database that has a couple hundred tables whose names make no sense to you, trying to figure out how tickets are stored and what you have to do to modify a ticket to mask the credit card.
And somewhere in here, you should be thinking about how you will write a script to scan for these things, so you don't have to rely on support people noticing them and calling them to your intention. You'll have fun discovering the various ways people can vary the formatting of credit card numbers. When you make your credit card number recognizer handle enough weird formatting to work well, then you'll find someone that gave you a zip code (5 digits), and a phone number including the '1' for long distance, and formatted those so weirdly that your credit card recognizer flagged them.
...and let's not forget about chat. If you do support via chat, you will have people typing in credit card numbers. If you are lucky, your chat system is part of your help desk system, and so while you were reverse engineering that to deal with credit card numbers in ticket, you happened to figure out where and how it stores chat logs.
If you do NOT automate dealing with email and chat, at some point a support person is going to bring to your attention a ticket or chat log with a credit card number, and you'll go into the database and fix it. If you are lucky, the support people noticed it quickly. If you are unlucky, it was sitting there for a while--and so it is now on your backups.
[1] http://www.callguard.co
For instance, suppose you allow orders over the telephone. A customer can call, talk to a salesperson, and then place an order. The customer will read their credit card information over the phone and the salesperson will enter it into the ordering system.
If your phone system is a VOIP system, congratulations! It's in scope for PCI! Since you probably don't want to have to deal with PCI for every phone in the company, you'll probably end up having to segment your system, so you can restrict sales calls to one segment.
If you are recording some sales calls so that managers can review them for training purposes, you either have to find a way to not record the parts of calls where credit card numbers are read, or you have to treat the recording as sensitive cardholder data and encrypt it. You might think you could just encrypt all the recordings and be done with it. Sadly, that's not good enough, because of the CSC code. You are not allowed to store the CSC code even if you do encrypt it.
Some people implement a system whereby the salesperson can press a button when the customer is about the give sensitive information, and that pauses recording for a few seconds. From what I've read, this is NOT sufficient for PCI compliance.
There are some approaches (aside from giving up on recording) that appear to be acceptable.
1. There is a system called CallGuard [1]. You integrate this with your phone system and your order entry system. When it is time for the caller to enter their card number and CSC, they do so with their phone keypad instead of by voice. CallGuard blocks the touch tones from the recording, interprets them, and enters them into your order system.
2. You can make it so that when a salesperson brings up the card number and CSC entry form, that automatically pauses recording until the form is submitted.
3. You can temporarily transfer the call to an interactive voice response system that gets the numbers and puts them in your order form, and then transfers the customer back to you.
Next up--email! A customer's recurring payment fails because they did not update their account when they got a new card. Your system sends them an email. The customer wants to update their card in response. Some will try to do this by email. They will fire of an email to your support address that tells you they have a new card and includes the number.
Now you've got a credit card number stored in the mailboxes of everyone who receives copies of support requests, and you'll have to do something about this. At least with a credit card in a mailbox, it's likely to be in a fairly standard and documented format.
If your company is big enough to have outgrown handling support requests by having a "support" mailbox that all your support people read, you probably have some kind of help desk system, and that's where that customer email with the credit card number ends up. So now you find yourself digging around in some big PHP codebase, and poking around a MySQL database that has a couple hundred tables whose names make no sense to you, trying to figure out how tickets are stored and what you have to do to modify a ticket to mask the credit card.
And somewhere in here, you should be thinking about how you will write a script to scan for these things, so you don't have to rely on support people noticing them and calling them to your intention. You'll have fun discovering the various ways people can vary the formatting of credit card numbers. When you make your credit card number recognizer handle enough weird formatting to work well, then you'll find someone that gave you a zip code (5 digits), and a phone number including the '1' for long distance, and formatted those so weirdly that your credit card recognizer flagged them.
...and let's not forget about chat. If you do support via chat, you will have people typing in credit card numbers. If you are lucky, your chat system is part of your help desk system, and so while you were reverse engineering that to deal with credit card numbers in ticket, you happened to figure out where and how it stores chat logs.
If you do NOT automate dealing with email and chat, at some point a support person is going to bring to your attention a ticket or chat log with a credit card number, and you'll go into the database and fix it. If you are lucky, the support people noticed it quickly. If you are unlucky, it was sitting there for a while--and so it is now on your backups.
[1] http://www.callguard.co
> The activity isn't harming you, it only "harms" the people with a relationship with the company.
This is not true. As a vendor, I assume costs associated with PCI compliance and other industry-standard best practices. If my competitor is ignoring these I am fundamentally disadvantaged. It's not an equal marketplace at that point.
Whether intentional on the competitor's part or not, this is saving them money and placing their customers at risk of identity theft, financial fraud and who knows what else depending on what's stored in that database.
> But reporting him to the authorities? That's very Stasi-esque.
Holy hyperbole, Batman. As a customer, I deserve to know if my vendor is eschewing industry-standard security practices. And they should be mercilessly shamed if they are.
This is not true. As a vendor, I assume costs associated with PCI compliance and other industry-standard best practices. If my competitor is ignoring these I am fundamentally disadvantaged. It's not an equal marketplace at that point.
Whether intentional on the competitor's part or not, this is saving them money and placing their customers at risk of identity theft, financial fraud and who knows what else depending on what's stored in that database.
> But reporting him to the authorities? That's very Stasi-esque.
Holy hyperbole, Batman. As a customer, I deserve to know if my vendor is eschewing industry-standard security practices. And they should be mercilessly shamed if they are.
The activity isn't harming you, it only "harms" the people with a relationship with the company
Actually, no. If the CC numbers are used fraudulently, the clients of that company will just issue chargebacks; at most, they'll need to get new cards. The people who'll have to pay are the merchants who will get hit with those chargebacks - and indirectly everyone else, since prices are raised to pay for those losses.
Actually, no. If the CC numbers are used fraudulently, the clients of that company will just issue chargebacks; at most, they'll need to get new cards. The people who'll have to pay are the merchants who will get hit with those chargebacks - and indirectly everyone else, since prices are raised to pay for those losses.
While PCI compliance might not be as important as dumping toxic waste, it's sure as hell more important than whether you smoke pot in your garage.
I think it's a dick move to only care about something when it affects yourself.
Are you advocating that unless you're black, you shouldn't have supported (or got involved with) the black civil rights movement?
Are you advocating that unless you're black, you shouldn't have supported (or got involved with) the black civil rights movement?
It may not be harming YOUR customers, but I don't agree with the premise that you only have an ethical obligation to protect the people paying you. The competitor's bad practice vastly increases their customer's risk of having their cards stolen, not only by people who break through the "security", but also by disgruntled employees.
Thank you for your support.
Edit:: I have not made up my mind yet. Admittedly, at the time of posting I was leaning more toward that side.
After reading everyone's advice, I'm leaning more toward a multi-tiered approach as @jacquesm suggested. It seems to avoid bad karma and burning bridges. Also, it seems as though the PCI Industry rarely acts on reports. So, working with the competitor to fix their issues could be the best thing down the road. It's a very small industry, and the possibility of a buy-out could exist in a few years.
Edit:: I have not made up my mind yet. Admittedly, at the time of posting I was leaning more toward that side.
After reading everyone's advice, I'm leaning more toward a multi-tiered approach as @jacquesm suggested. It seems to avoid bad karma and burning bridges. Also, it seems as though the PCI Industry rarely acts on reports. So, working with the competitor to fix their issues could be the best thing down the road. It's a very small industry, and the possibility of a buy-out could exist in a few years.
It sounds like you've already made up your mind and are just looking for people to agree with you.
This is the vibe I was getting, which is unfortunate. Of course I'm only speculating.
Similarly, I find it to be insanely frustrating when people ask for advice, but are not willing to listen when they get it. It feels dishonest.
Similarly, I find it to be insanely frustrating when people ask for advice, but are not willing to listen when they get it. It feels dishonest.
Not agreeing with advice doesn't mean the recipient didn't listen to or appreciate it.
A recipient could have listened. A recipient could have not listened. I still think it is dishonest when it is someone's intention to fish for agreements. I originally speculated as to whether this was the case, and he/she has said otherwise.
(a) TALK TO A LAWYER FIRST
(b) It seems to me that the customer in question is in a much better position to file a complaint than you are. I can't see anything wrong (but see (a)) with writing them a detailed letter explaining the implications of what you found during the transfer. They will probably not want to act on it, but if they do, they can't be accused of ulterior motives.
(c) You could try the tack of advertising very loudly that you're PCI compliant, without ever mentioning your competitor. (Is there third-party PCI certification? If so, you might want to get it.) Yes, everyone who handles credit cards is supposed to be PCI compliant, but customers don't necessarily know that; you could perhaps make it a differentiator. If your competitor is so unscrupulous as to advertise themselves as compliant when they're not, possibly (see (a)) you could then report them yourself.
(b) It seems to me that the customer in question is in a much better position to file a complaint than you are. I can't see anything wrong (but see (a)) with writing them a detailed letter explaining the implications of what you found during the transfer. They will probably not want to act on it, but if they do, they can't be accused of ulterior motives.
(c) You could try the tack of advertising very loudly that you're PCI compliant, without ever mentioning your competitor. (Is there third-party PCI certification? If so, you might want to get it.) Yes, everyone who handles credit cards is supposed to be PCI compliant, but customers don't necessarily know that; you could perhaps make it a differentiator. If your competitor is so unscrupulous as to advertise themselves as compliant when they're not, possibly (see (a)) you could then report them yourself.
Don't be under the impression that reporting a PCI violation will matter. They'll just apply a bandage if anyone looks into it. The real risk is if they have a breach, then they'll be liable for more fines. I know businesses that are very successful and ignore PCI. One even sold for a large amount of money. They implemented BrainTree in a week to solve a due diligence issue. No big deal. Sure, if they'd been hacked it'd have really hurt, but they weren't and now have FU money.
For it to actually really hurt your competitor, you'd have to probably astroturf some forums, acting like concerned customers, and get other customers upset. And even then, you're just going to cost them a week or so. Maybe if you timed it for maximum damage, but just don't waste too much time on it.
For it to actually really hurt your competitor, you'd have to probably astroturf some forums, acting like concerned customers, and get other customers upset. And even then, you're just going to cost them a week or so. Maybe if you timed it for maximum damage, but just don't waste too much time on it.
I thought PCI compliance wasn't necessarily legally required, just that it was a contractual agreement between your company and the payment processor?
Regardless, I still feel reporting is the ethical thing to do.
Regardless, I still feel reporting is the ethical thing to do.
1. FALSE ADVERTISING: If the competitor advertises PCI compliance --- or even advertises "we're secure" --- that's very possibly false advertising in violation of Section 43(a) of the Lanham Act [1] and perhaps various state deceptive-trade-practices statutes. Some years back, U-Haul got a $44 million judgment against a competitor whose ads for rental trucks included inaccurate dimensions. The damages award was tied to the cost of corrective advertising that U-Haul would theoretically have to do. [2]
2. TORTIOUS INTERFERENCE COUNTERCLAIM: The competitor's terms of service with the customer probably include restrictions on access to the competitor's system. The competitor thus might claim that the OP's accessing of the customer's data constituted "tortious interference" with the competitor-customer contract. [3] The competitor's lawyers are likely to pursue such a claim, because it lets them reframe the issue in their favor, it might allow them greater discovery from the OP, and it could also lead to a punitive-damages award. (Whether a tortious-interference claim would succeed depends on a lot of facts that we don't have.)
3. CFAA VIOLATION: As others have pointed out, depending on the circumstances, the OP might have violated the Computer Fraud and Abuse Act. [4]
All of the above assumes U.S. law applies.
[1] http://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=...
[2] U-Haul v. Jartran, 793 F. 2d 1034, 1041 (9th Cir. 1986) http://scholar.google.com/scholar_case?case=1381884152605222...
[3] https://en.wikipedia.org/wiki/Tortious_interference
[4] https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
2. TORTIOUS INTERFERENCE COUNTERCLAIM: The competitor's terms of service with the customer probably include restrictions on access to the competitor's system. The competitor thus might claim that the OP's accessing of the customer's data constituted "tortious interference" with the competitor-customer contract. [3] The competitor's lawyers are likely to pursue such a claim, because it lets them reframe the issue in their favor, it might allow them greater discovery from the OP, and it could also lead to a punitive-damages award. (Whether a tortious-interference claim would succeed depends on a lot of facts that we don't have.)
3. CFAA VIOLATION: As others have pointed out, depending on the circumstances, the OP might have violated the Computer Fraud and Abuse Act. [4]
All of the above assumes U.S. law applies.
[1] http://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=...
[2] U-Haul v. Jartran, 793 F. 2d 1034, 1041 (9th Cir. 1986) http://scholar.google.com/scholar_case?case=1381884152605222...
[3] https://en.wikipedia.org/wiki/Tortious_interference
[4] https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
QSA here. In a nutshell, I'd say don't. PCI compliance is enforced by the card brands and acquirers, so it's not up to you to raise a flag here. Maybe they have compensating controls in place to address those issues (one can be PCI compliant while storing cardholder data in clear-text) and, depending on the line of business, they might have a business justification for storing security codes (unusual, but it can happen). Ultimately, it's not your call. What you might perceive as a violation could very well be a known issue with several compensating controls in place to minimize the risk and, if that's OK with the card brands and/or acquirers, your competitor is doing nothing wrong. Leave it to their QSA to determine their compliance status and to their acquirer to make sure that they're compliant.
Your competitor's merchant processor should have an audit process where this is discovered.
It is unlikely that reporting it to said merchant processor will result in account termination since if your competitor is not at the level where an audit is required, he/she is simply filling out a form.
Incidentally, PCI-DSS 3.0 went into effect today, so anyone using Heroku for commerce became non-compliant today!
https://www.google.com/#safe=off&q=add%20to%20cart%20site%3A...
It is unlikely that reporting it to said merchant processor will result in account termination since if your competitor is not at the level where an audit is required, he/she is simply filling out a form.
Incidentally, PCI-DSS 3.0 went into effect today, so anyone using Heroku for commerce became non-compliant today!
https://www.google.com/#safe=off&q=add%20to%20cart%20site%3A...
The Heroku situation is more nuanced than it seems. This is not a PCI DSS 3.0 issue. The thing is that Heroku provides a platform and this platform is not PCI DSS compliant (1.21, 2.0, 3.0, you name it) and Heroku is not willing to let QSAs verify their compliance on behalf of their clients (and, yes, I have first hand experience with this very scenario). There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go. Let's say you use a payment gateway and cardholder data never touches your Heroku environment (e.g. you're redirected to Payment Gateway XYZ's app to enter your payment information). In this case your Heroku environment would be potentially out of scope, as you're not transmitting, storing or processing cardholder data. If you're handling cardholder data in any capacity in your Heroku environment, then, yes, you're in for a big compliance surprise.
> Heroku is not willing to let QSAs verify their compliance on behalf of their clients
This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes.
> There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go
Not true, see below:
https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-...
This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes.
> There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go
Not true, see below:
https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-...
>This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes.
Exactly. And, personally, I think this is rather odd. They could solve this in a heartbeat.
>Not true, see below:
Duly noted and thanks for the link, but here's the thing, though: what if you're not eligible for a self-assessment?
Exactly. And, personally, I think this is rather odd. They could solve this in a heartbeat.
>Not true, see below:
Duly noted and thanks for the link, but here's the thing, though: what if you're not eligible for a self-assessment?
> what if you're not eligible for a self-assessment
If you're doing higher transaction volume and are not eligible for a self-assessment, you have to have a certified QSA sign off on an audit of the internal processes.
The QSA will make sure that all the required systems and processes are in place and sign off on it.
PCI is definitely a fairly frustrating thing to deal with but there are some good practices underlying it that many orgs would simply not do if it weren't required by their merchant processor.
If you're doing higher transaction volume and are not eligible for a self-assessment, you have to have a certified QSA sign off on an audit of the internal processes.
The QSA will make sure that all the required systems and processes are in place and sign off on it.
PCI is definitely a fairly frustrating thing to deal with but there are some good practices underlying it that many orgs would simply not do if it weren't required by their merchant processor.
"Incidentally, PCI-DSS 3.0 went into effect today, so anyone using Heroku for commerce became non-compliant today!"
Can you elaborate a bit on that? Thank you.
Can you elaborate a bit on that? Thank you.
more details here:
https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.p...
http://blog.spreedly.com/2014/03/26/saq-a-ep-a-big-shakeup-f...
If you want to use a PAAS and want to be able to pass any kind of infrastructure audit, the fastest path is probably via Aptible (YC S14)
https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.p...
http://blog.spreedly.com/2014/03/26/saq-a-ep-a-big-shakeup-f...
If you want to use a PAAS and want to be able to pass any kind of infrastructure audit, the fastest path is probably via Aptible (YC S14)
Still not sure. What counts, and what doesn't? Does this mean that any service you host on Heroku has to be free? You can't integrate Stripe and accept payments?
The main thing to remember about the deadline today is that what's changed is the forms needed for certification. If you're already certified, nothing changes today - but when you do your annual re-certification, you'll need to use the 3.0 forms (and not the 2.0 ones). Until such point, you're still certified and compliant. If you're not yet already certified, you'll need to use the 3.0 forms; this is what most people are referring to.
With that in mind, this discussion only applies (right now) to sites who have never yet filled out a PCI form. For sites which have, it only applies when their annual re-certification comes up.
So for those sites which have to certify against 3.0, can they run on a PAAS and take payments? It depends, specifically on how the credit card number is entered. The general rule of thumb is that if the form in which the number is entered is delivered by the host (the PAAS), you'll have to use SAQ A-EP (which is extensive, and you don't want). if the form is delivered by the vendor (like Stripe) and injected into the page, you can still use SAQ A (which is small, and what you want).
How about Stripe? I'm not sure if they've released a PCI 3.0 version of Stripe.js yet, although they clearly will. Likewise, I'm not sure about the others, but I think it's safe to assume that they'll release versions similarly (the techniques to do this are well-known).
Lastly, I'm not a QSA, and this isn't advice.
With that in mind, this discussion only applies (right now) to sites who have never yet filled out a PCI form. For sites which have, it only applies when their annual re-certification comes up.
So for those sites which have to certify against 3.0, can they run on a PAAS and take payments? It depends, specifically on how the credit card number is entered. The general rule of thumb is that if the form in which the number is entered is delivered by the host (the PAAS), you'll have to use SAQ A-EP (which is extensive, and you don't want). if the form is delivered by the vendor (like Stripe) and injected into the page, you can still use SAQ A (which is small, and what you want).
How about Stripe? I'm not sure if they've released a PCI 3.0 version of Stripe.js yet, although they clearly will. Likewise, I'm not sure about the others, but I think it's safe to assume that they'll release versions similarly (the techniques to do this are well-known).
Lastly, I'm not a QSA, and this isn't advice.
I think you're incorrect. An attacker could simply change the code on your server to make the form submit to a malicious location. The user would never know there was an attack going on.
The entire point of SAQ A-EP is to cover the edge case that was letting people use offsite, iframe, and js checkouts. It puts the web server that is doing the hosting of the site in general into PCI scope.
The entire point of SAQ A-EP is to cover the edge case that was letting people use offsite, iframe, and js checkouts. It puts the web server that is doing the hosting of the site in general into PCI scope.
It puts the web server that is doing the hosting of the site in general into PCI scope.
So essentially, every card payment service where the merchant's web site touches the payment flow beyond directly linking to an entire page hosted by a third party is dead? Because on a literal reading, I don't see how any of those services or the merchants using them can possibly be exempt from the new rules, and I don't see how it is going to be commercially viable for any small merchant using any of those services to comply. Say goodbye to Stripe and its various clones, Checkout or otherwise. Forget using any sort of A/B testing on your sign-up pages that isn't entirely self-hosted, or using any third party analytics to track visitors through the flow. Basically, you can use a fully hosted service provided by a major bank (and we all know how well those convert and how well the giant financial services firms typically treat small businesses) or you're out of luck.
If that is really what the new rules are meant to say then this appears to be dumb on an EU VAT mess scale of dumb, with the added dumbness that since it's not actually a legal requirement to comply with PCI DSS, roughly 0% of merchants who should in theory be affected actually will. All it's going to do is reinforce the image of the card payment industry as a dinosaur and hasten its demise by destroying the best idea they've had in years: allowing small businesses to actually take card payments on-line without jumping through silly numbers of hoops.
So essentially, every card payment service where the merchant's web site touches the payment flow beyond directly linking to an entire page hosted by a third party is dead? Because on a literal reading, I don't see how any of those services or the merchants using them can possibly be exempt from the new rules, and I don't see how it is going to be commercially viable for any small merchant using any of those services to comply. Say goodbye to Stripe and its various clones, Checkout or otherwise. Forget using any sort of A/B testing on your sign-up pages that isn't entirely self-hosted, or using any third party analytics to track visitors through the flow. Basically, you can use a fully hosted service provided by a major bank (and we all know how well those convert and how well the giant financial services firms typically treat small businesses) or you're out of luck.
If that is really what the new rules are meant to say then this appears to be dumb on an EU VAT mess scale of dumb, with the added dumbness that since it's not actually a legal requirement to comply with PCI DSS, roughly 0% of merchants who should in theory be affected actually will. All it's going to do is reinforce the image of the card payment industry as a dinosaur and hasten its demise by destroying the best idea they've had in years: allowing small businesses to actually take card payments on-line without jumping through silly numbers of hoops.
> beyond directly linking to an entire page hosted by a third party
No, including payment pages hosted by a third party:
https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-...
The important thing to note is that it would not be very difficult for Heroku to allow websites to gain compliance. One should be able to type:
The other half would easily be covered by publishing general policy documents about data center policies, etc., similar to what Amazon already publishes. Heroku can simply reference all the existing AWS service provider documentation and then add a few of its own documents covering the stuff it manages (things like password control policies, etc.) Also it would be helpful to allow the admin panel to require multi-factor auth.
So it's not really all that absurd. For all we know Heroku has a few massively glaring security holes and as we type people are skimming lots of payment information...
PCI is not a legal requirement, simply a moderate quality list of best practices. That Heroku and other PAAS vendors have trouble doing this should probably be cause for some actual concern.
No, including payment pages hosted by a third party:
https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-...
The important thing to note is that it would not be very difficult for Heroku to allow websites to gain compliance. One should be able to type:
$ heroku document:network
The other half would easily be covered by publishing general policy documents about data center policies, etc., similar to what Amazon already publishes. Heroku can simply reference all the existing AWS service provider documentation and then add a few of its own documents covering the stuff it manages (things like password control policies, etc.) Also it would be helpful to allow the admin panel to require multi-factor auth.
So it's not really all that absurd. For all we know Heroku has a few massively glaring security holes and as we type people are skimming lots of payment information...
PCI is not a legal requirement, simply a moderate quality list of best practices. That Heroku and other PAAS vendors have trouble doing this should probably be cause for some actual concern.
If that summary is accurate then it's even worse -- not only are Stripe and friends dead, but so are all the "hosted" solutions offered by banks. You literally can't run a web site and take card payments without either (a) building the entire site using some sort of marketplace or other compliant service, or (b) complying with exactly the kind of onerous PCI DSS burden that all those hosted payment pages and services like Stripe were designed to avoid.
As far as I can see, the only significant attack that this addresses is someone compromising your site and changing it to redirect to a malicious alternative instead of your real payment service. But since any fool can set up a site that looks the same, has a similar domain name, ranks about the same in Google, but is entirely fictitious and exists only to harvest cardholder data, and moreover following that strategy would be far easier than compromising a legitimate merchant's site in many cases, this is a poor attempt to mitigate a threat that is in practice impossible to avoid.
If this is really all true then I'm pretty sure PCI DSS just became irrelevant to most small on-line businesses. There's no commercially reasonable way for them to comply with those terms. There's no legal threat if they don't (at least not in most places; YMMV) so we're purely talking about financial liability here. And from a financial point of view, you might as well just accept that if you get a breach and card data leaks then your business will go bankrupt paying the fines whatever you do, so you can ignore the whole thing anyway. The only other meaningful sanction the card services have is refusing to allow the same company representatives to take card payments at other companies in the future, but if they would do that for this reason then probably you were never going to work with them again anyway.
As far as I can see, the only significant attack that this addresses is someone compromising your site and changing it to redirect to a malicious alternative instead of your real payment service. But since any fool can set up a site that looks the same, has a similar domain name, ranks about the same in Google, but is entirely fictitious and exists only to harvest cardholder data, and moreover following that strategy would be far easier than compromising a legitimate merchant's site in many cases, this is a poor attempt to mitigate a threat that is in practice impossible to avoid.
If this is really all true then I'm pretty sure PCI DSS just became irrelevant to most small on-line businesses. There's no commercially reasonable way for them to comply with those terms. There's no legal threat if they don't (at least not in most places; YMMV) so we're purely talking about financial liability here. And from a financial point of view, you might as well just accept that if you get a breach and card data leaks then your business will go bankrupt paying the fines whatever you do, so you can ignore the whole thing anyway. The only other meaningful sanction the card services have is refusing to allow the same company representatives to take card payments at other companies in the future, but if they would do that for this reason then probably you were never going to work with them again anyway.
You are missing the details.
Stripe and similar services are themselves PCI compliant and have extensive documentation, audits, etc.
Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.
PAAS vendors are one of the most likely attack vectors which is why they are in scope with SAQ A-EP.
If you are seriously under the impression that you could easily set up silhouettesfakeamazon.com and start harvesting credit cards, I challenge you to try it :)
Stripe and similar services are themselves PCI compliant and have extensive documentation, audits, etc.
Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.
PAAS vendors are one of the most likely attack vectors which is why they are in scope with SAQ A-EP.
If you are seriously under the impression that you could easily set up silhouettesfakeamazon.com and start harvesting credit cards, I challenge you to try it :)
I understand that the payment services are PCI compliant. But on a literal reading of the actual PCI DSS 3 documentation, specifically who is covered by the new A-EP case, that doesn't appear to help unless the entire "shopping" part of the site is also hosted by a merchant or third party service that is PCI compliant.
Otherwise, the merchant still appears to come into scope, because at some point they must redirect their customer to the externally hosted payment pages or load the externally hosted checkout system from the merchant's site, one way or another.
So basically, it looks like anyone who has any sort of shopping site they run themselves (as opposed to hosting entirely on a third party marketplace site) but who uses Stripe, PayPal, a hosted card payment page offered by their bank, or literally any other third party card payment system, will fall into scope and be required to operate and audit the entire relevant part of their web site according to the PCI DSS 3 rules. But that is obviously far beyond the reasonable capabilities of most merchants who might find themselves in that position, either technically or commercially.
Edit: In short, when you wrote:
Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.
I haven't yet found anything that says why such a site doesn't fall into scope now just like everyone else. Indeed, the new rules seem to be clearly aimed at such sites as I read them.
Otherwise, the merchant still appears to come into scope, because at some point they must redirect their customer to the externally hosted payment pages or load the externally hosted checkout system from the merchant's site, one way or another.
So basically, it looks like anyone who has any sort of shopping site they run themselves (as opposed to hosting entirely on a third party marketplace site) but who uses Stripe, PayPal, a hosted card payment page offered by their bank, or literally any other third party card payment system, will fall into scope and be required to operate and audit the entire relevant part of their web site according to the PCI DSS 3 rules. But that is obviously far beyond the reasonable capabilities of most merchants who might find themselves in that position, either technically or commercially.
Edit: In short, when you wrote:
Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.
I haven't yet found anything that says why such a site doesn't fall into scope now just like everyone else. Indeed, the new rules seem to be clearly aimed at such sites as I read them.
You are correct, however if you read over the requirements, they are not all that crazy. If you have an e-commerce website that has all ports open stores credit cards in clear text, etc., then you will fail, but it's actually pretty easy for a shop with its own servers and network team (in-house or outsourced) to come up with a network diagram that satisfies the PCI DSS 3.0 SAQ requirements.
The issue is that Heroku, because of its lack of transparency about what is actually going on in its routing mesh, is not necessarily secure, and it's not possible to just download a list of relevant firewall rules, etc. (the way you could if you set up a site on Amazon VPC).
SAQ A has always required the merchant using his/her own servers to provide some documentation and do some security scanning, the new thing with SAQ A-EP is that it no longer allows for the loophole of using a PAAS and claiming that simply b/c it is not managed by the e-commerce shop that it is out of scope.
The issue is that Heroku, because of its lack of transparency about what is actually going on in its routing mesh, is not necessarily secure, and it's not possible to just download a list of relevant firewall rules, etc. (the way you could if you set up a site on Amazon VPC).
SAQ A has always required the merchant using his/her own servers to provide some documentation and do some security scanning, the new thing with SAQ A-EP is that it no longer allows for the loophole of using a PAAS and claiming that simply b/c it is not managed by the e-commerce shop that it is out of scope.
PCI covers the handling of payment information. So any service on Heroku can't handle payment data unless in the form of a token. Hosting a form that posts to a 3rd party host is what has now become "in scope" with v3.0 of PCI DSS.
Re: PCI-DSS 3
Uh no, if you qualify for PCI SAQ A, you are fine (so if you link off site, or use an iframe to collect info - like Stripe Checkout). If you used a direct post method or some JS tokenization, its likely that you know fall under the PCI SAQ A-EP rules which would require PCI compliant hosting.
Not sure where you got that idea. The entire purpose of SAQ A-EP is to bring the hosting site into PCI scope.
Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js?
This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0
Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js?
This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0
https://www.pcisecuritystandards.org/documents/Understanding...
There is a comparison of PCI SAQ A and EP, if all you do is link to a 3rd party site (or load an iFrame) and the CC is loaded in that PCI compliant site, you are OK in SAQ A.
Stripe.js is tricky. Stripe says their QSA has verified that the new version of Stripe.js will let their merchants qualify for SAQ A since the transport of credit card info happens through a iframe (you can see the updated Stripe.js https://js.stripe.com/v2/stripe-dss3-debug.js). I personally disagree with that, but Stripe Checkout definitely falls under SAQ A.
Per the linked doc: What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A? SAQ A: Merchant website provides an inline frame (iFrame)to a PCI DSS compliant third-party processor facilitating the payment process.
SAQ A-EP: Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.
There is a comparison of PCI SAQ A and EP, if all you do is link to a 3rd party site (or load an iFrame) and the CC is loaded in that PCI compliant site, you are OK in SAQ A.
Stripe.js is tricky. Stripe says their QSA has verified that the new version of Stripe.js will let their merchants qualify for SAQ A since the transport of credit card info happens through a iframe (you can see the updated Stripe.js https://js.stripe.com/v2/stripe-dss3-debug.js). I personally disagree with that, but Stripe Checkout definitely falls under SAQ A.
Per the linked doc: What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A? SAQ A: Merchant website provides an inline frame (iFrame)to a PCI DSS compliant third-party processor facilitating the payment process.
SAQ A-EP: Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.
I would agree. If you have the form markup in your page, then your JS can siphon off card details (with an iFrame rendered by someone else with the form in the iFrame, you cannot). I do not know the full story on the Stripe DSS3 code but it's trivial in their payment-form submit event handler to grab details before calling Stripe.card.createToken.
It would be trivial, which is one of the problems with A-EP when you look at it from the POV of someone who knows something about web security.
As for iFrames vs. Direct POST, from https://www.pcisecuritystandards.org/documents/Understanding...:
Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')
As for iFrames vs. Direct POST, from https://www.pcisecuritystandards.org/documents/Understanding...:
Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')
Right. Which is why SAQ A-EP was invented -- to prevent merchants from gaining compliance based on the loophole that they are using a js library or offsite link to collect payment.
it would be trivial but the iframe (Stripe Checkout) does qualify for SAQ A.
Correct: The use or non-use of stripe.js is irrelevant for whether a merchant needs SAQ A or SAQ A-EP.
SAQ A applies when using one's own server infrastructure, and SAQ A-EP applies when using a PAAS.
SAQ A applies when using one's own server infrastructure, and SAQ A-EP applies when using a PAAS.
Didn't PCI-DSS 3.0 go into effect January 1, 2014?
Edit: The new questionnaires went into effect today. The previous year's were still applicable through last year.
Edit: The new questionnaires went into effect today. The previous year's were still applicable through last year.
Who is their Visa Qualified Security Assessor? If there is a corrupt Security Assessor, the problem is bigger than one processor. Are they on the Visa registry of Qualified Service Providers (http://www.visa.com/splisting/searchGrsp.do)? If either of those is the case, this is a big problem. Report it to Visa.
Or is this some small operation which provides services for a niche market and is below the 300,000 transactions/year where it gets serious? Then, maybe not so much.
Visa is quite serious about enforcing those standards. They took away every user-facing credit card reader from Barnes and Noble for a year after a breach. They took away Sony Online's ability to accept credit cards at all for several weeks after Sony had a breach.
Or is this some small operation which provides services for a niche market and is below the 300,000 transactions/year where it gets serious? Then, maybe not so much.
Visa is quite serious about enforcing those standards. They took away every user-facing credit card reader from Barnes and Noble for a year after a breach. They took away Sony Online's ability to accept credit cards at all for several weeks after Sony had a breach.
> If there is a corrupt Security Assessor, the problem is bigger than one processor
Huh? As a service provider who has to deal with these third parties (for our hosted/colo type of clients) I would say I have yet to find one that isn't corrupt.
They basically are completely worthless, at least at the lower-tiers. They more or less run nmap and a nessus scan, and then tell the client how to game those scans without improving security whatsoever (e.g. hiding an exploitable version of PHP's version banner, firewalling the test probe IPs from certain ports the world can see, etc.).
In fact, from a service provider perspective PCI has made things less secure since we no longer have as much traction with clients when we tell them they need to do X to store financial data securely. Now they can point to their "audit" and say it's fine.
> Visa is quite serious about enforcing those standards.
Not in my experience. They only seem to care after a breach happens and only for PR purposes. Report anything before that, and from what I can tell it's completely ignored.
That said, we generally don't deal with the higher compliance levels - those that do, seem to get it more or less right (or at least put resources and thought into it if nothing else).
Huh? As a service provider who has to deal with these third parties (for our hosted/colo type of clients) I would say I have yet to find one that isn't corrupt.
They basically are completely worthless, at least at the lower-tiers. They more or less run nmap and a nessus scan, and then tell the client how to game those scans without improving security whatsoever (e.g. hiding an exploitable version of PHP's version banner, firewalling the test probe IPs from certain ports the world can see, etc.).
In fact, from a service provider perspective PCI has made things less secure since we no longer have as much traction with clients when we tell them they need to do X to store financial data securely. Now they can point to their "audit" and say it's fine.
> Visa is quite serious about enforcing those standards.
Not in my experience. They only seem to care after a breach happens and only for PR purposes. Report anything before that, and from what I can tell it's completely ignored.
That said, we generally don't deal with the higher compliance levels - those that do, seem to get it more or less right (or at least put resources and thought into it if nothing else).
They might be self-certifying. In that case they're small fry.
Why are so many people pretending this is being done for the good of the users? I got started in my business because I loved what I was doing (for my users). I stayed because it makes me a boatload full of money. If I see my competitor slipping, I want to take advantage of them. Sure I do have empathy for the users but at the end of the day it is pretty clear.
Believe me, if your competitor saw you doing this stuff they would definitely report you. Kill or be killed. You think Marc Cuban or Donald Trump is worried about their users when they have an opportunity to take advantage of a competitor?
Believe me, if your competitor saw you doing this stuff they would definitely report you. Kill or be killed. You think Marc Cuban or Donald Trump is worried about their users when they have an opportunity to take advantage of a competitor?
If your competitor saw you doing 'this stuff' they might report you, they might not. It's not a certainty and having seen enough situations like this over the years it strikes me as immature to think that by damaging your competitor you are immediately strengthening your own position. Rather the opposite, you are damaging the entire field in which you operate, which includes your own company.
Second, it's not kill or be killed, if that was all there was to it then why not hire some Russian goon squad to bring down your competitors web-site? After all, they could do the same to you... Most likely the idea that all of the competitors business would be taken over and that they'd go spectacularly bust is a pipe dream at best.
And let's let Marc Cuban speak for himself (as far as I know he's not going to stoop so low as to intentionally damage a competitor for his own advantage), for Donald Trump I'll hold up the inconclusive data flag.
If you run your business the way you do then it will definitely reflect back on you in most cases, you'll find that one day the tables are going to be turned and then you'll be all out of sympathy.
Sure, business is ruthless. But it does not automatically mean that you can back-stab your competitors for your own glorification. And if it does then I'd rather not be part of your circle, toxic attitudes create toxic environments.
If you think that the only way you can grow your company is at someone else's expense then maybe it's time you spent a few $ on marketing instead? Very rare to find an ocean empty of fish.
Second, it's not kill or be killed, if that was all there was to it then why not hire some Russian goon squad to bring down your competitors web-site? After all, they could do the same to you... Most likely the idea that all of the competitors business would be taken over and that they'd go spectacularly bust is a pipe dream at best.
And let's let Marc Cuban speak for himself (as far as I know he's not going to stoop so low as to intentionally damage a competitor for his own advantage), for Donald Trump I'll hold up the inconclusive data flag.
If you run your business the way you do then it will definitely reflect back on you in most cases, you'll find that one day the tables are going to be turned and then you'll be all out of sympathy.
Sure, business is ruthless. But it does not automatically mean that you can back-stab your competitors for your own glorification. And if it does then I'd rather not be part of your circle, toxic attitudes create toxic environments.
If you think that the only way you can grow your company is at someone else's expense then maybe it's time you spent a few $ on marketing instead? Very rare to find an ocean empty of fish.
First, a disclaimer. I am not a lawyer, nor am I even American, so all of this should be taken with the understanding that I'm really not qualified.
I don't know how you found these violations and, for all I know, you may not even be in the United States, but if you are, I would consider speaking with an attorney (preferably one with experience working cybercrime cases) to make sure that you aren't going to stumble into CFAA territory.
If I were your competitor, if I happened to find out that it was you, one option would be to call, "HACKER!! EVIL HACKER!!" And, looking at some recent cybercrime prosecutions (ie - aaronsw), if your competitor happened to catch the ear of the right prosecutor, you could be in heaps of trouble.
I hope that you do report this - your competitor honestly sounds like a scumbag. But, because he/she sounds like such a scumbag, they may not fade gracefully into obscurity. Protect yourself accordingly.
I don't know how you found these violations and, for all I know, you may not even be in the United States, but if you are, I would consider speaking with an attorney (preferably one with experience working cybercrime cases) to make sure that you aren't going to stumble into CFAA territory.
If I were your competitor, if I happened to find out that it was you, one option would be to call, "HACKER!! EVIL HACKER!!" And, looking at some recent cybercrime prosecutions (ie - aaronsw), if your competitor happened to catch the ear of the right prosecutor, you could be in heaps of trouble.
I hope that you do report this - your competitor honestly sounds like a scumbag. But, because he/she sounds like such a scumbag, they may not fade gracefully into obscurity. Protect yourself accordingly.
Unabashedly, Yes you should report them.
Yes it will benefit you, but more importantly it benefits his customers because it gives them additional facts they did not have before about the trustworthiness of the vendor they're using.
The fact that you are a competitor with this malicious actor should have no bearing on your decision.
Yes it will benefit you, but more importantly it benefits his customers because it gives them additional facts they did not have before about the trustworthiness of the vendor they're using.
The fact that you are a competitor with this malicious actor should have no bearing on your decision.
Assuming malice is rather presumptive. There's a big difference between negligence and malice. I'm certainly not defending the actions of this company (I have no idea who they are,) but I certainly wouldn't want someone's potential ignorance to be used to assert that they acted with an intent to harm. Malice requires intent. Acting stupidly isn't malicious.
Ignorance of the law will not protect you from it, neither will ignorance of security precautions prevent you from being hacked. People will always make mistakes, but you don't raise the bar by merely tolerating the status quo.
I think more people need to understand that security is important, implementing the security precautions that you're aware of isn't enough anymore. You need to be active in the community to make sure you're up to speed on recent developments, and that you're following Best Practices where possible. Anything less is insufficient.
It's us the customers who are hurt the most when company databases get hacked. Companies should start showing some respect for that fact by taking security seriously.
I think more people need to understand that security is important, implementing the security precautions that you're aware of isn't enough anymore. You need to be active in the community to make sure you're up to speed on recent developments, and that you're following Best Practices where possible. Anything less is insufficient.
It's us the customers who are hurt the most when company databases get hacked. Companies should start showing some respect for that fact by taking security seriously.
"Reporting" someone for a PCI violation won't do much. At most they might lose their certification level temporarily as their PCI auditor makes them implement fixes. In fact there might even be a grace period for them to fix problems, so no action will be visible to their customers. Even if they lose PCI certification, that's not something customers look for or know about.
If you want to damage their reputation, write a blog post in a way not traceable to your company exposing the actions of your competitor. Or get a news agency to notice, and be an anonymous source. This probably isn't worth the trouble.
The white hat solution, as others have mentioned, is tell them. If they don't have the problems resolved within some reasonable time span (a month if you're feeling mean, 6 months if you're feeling nice), then I would say you're morally justified in smearing the hell out of them.
If you want to damage their reputation, write a blog post in a way not traceable to your company exposing the actions of your competitor. Or get a news agency to notice, and be an anonymous source. This probably isn't worth the trouble.
The white hat solution, as others have mentioned, is tell them. If they don't have the problems resolved within some reasonable time span (a month if you're feeling mean, 6 months if you're feeling nice), then I would say you're morally justified in smearing the hell out of them.
Definitely.
This will also bring to light anyone complicit in the violations as well (e.g., companies contracted for performing audits, who aren't taking due diligence), so the benefit to everyone is more than just having your competitor clean up his act.
This will also bring to light anyone complicit in the violations as well (e.g., companies contracted for performing audits, who aren't taking due diligence), so the benefit to everyone is more than just having your competitor clean up his act.
I hadn't thought of that. Very interesting insight. Thanks!
Perhaps, just start emphasizing your superior security (and PCI compliance) in your marketing, in a very pointed way. ("Some competitors don't..." or "If considering a competitive offering, ask if they..." – but without specifically naming the competitor.)
Note that this doesn't always impress customers – and sometimes mentioning security concerns activates customer paranoia such that they convert at lower rates! So you may need to test this.
But, if your customers are security conscious, they'll notice the differences when comparing offerings. When they ask your competitor for details, the competitor will either offer false reassurances, or become increasingly aware of their deficiencies, and fix them. (And them fixing their issues may be in your best interest: a famous failure by your competitor could stain your whole category as too-risky for wider adoption by your target customers.)
If and when there is a damaging breach at any competitor, your practices (and marketing) going back to before the breach can help immunize you somewhat from the fallout, even without you ever directly naming the competitor or its failings. (To directly mention a competitor, or its specific troubles after an incident, could be seen as classless and easily backfire. Not only may you have a lapse yourself someday, but any 'gloating' may draw retaliation from competitors or extra attention from criminal hackers who get more glory when compromising systems that brag about their security.)
Note that this doesn't always impress customers – and sometimes mentioning security concerns activates customer paranoia such that they convert at lower rates! So you may need to test this.
But, if your customers are security conscious, they'll notice the differences when comparing offerings. When they ask your competitor for details, the competitor will either offer false reassurances, or become increasingly aware of their deficiencies, and fix them. (And them fixing their issues may be in your best interest: a famous failure by your competitor could stain your whole category as too-risky for wider adoption by your target customers.)
If and when there is a damaging breach at any competitor, your practices (and marketing) going back to before the breach can help immunize you somewhat from the fallout, even without you ever directly naming the competitor or its failings. (To directly mention a competitor, or its specific troubles after an incident, could be seen as classless and easily backfire. Not only may you have a lapse yourself someday, but any 'gloating' may draw retaliation from competitors or extra attention from criminal hackers who get more glory when compromising systems that brag about their security.)
You definitely should. It's unacceptable to have CC numbers in plain-text regardless if they are your competitor or not.
That's my biggest issue. The people who end up seeing the CC numbers are minimum wage receptionists.
I have a customer who told me that her manager's boyfriend was writing down customer's addresses to go rob them. The nature of the business indicates that the customer is not at their home for extended periods of time. We ended up building in user permissions to see name, address and phone number.
I have a customer who told me that her manager's boyfriend was writing down customer's addresses to go rob them. The nature of the business indicates that the customer is not at their home for extended periods of time. We ended up building in user permissions to see name, address and phone number.
Whoa, call the police maybe?
I would very strongly suggest you speak with a lawyer. What if you do the moral thing and said competitor sees you as trying to blackmail him or something even if your intentions are good? What if he responds with a proactive lawsuit? This isn't about anything other than CYA. An hour or so from a lawyer could save you a LOT of pain down the road.
> I've spent days debating the ethics of reporting or making this public. On the one hand, I'd be putting him out of business (and I'm well poised to scoop up those new prospects). On the other hand, he's putting people's finances at risk and I feel obligated to say something that the public may not be able to discern.
This raises an interesting hypothetical.
Let's suppose that there was no PCI violation, or any other ethical or legal problem with his business, but that through better pricing, service, more effective advertising, or something like that, you found yourself taking away business from him to the point that he might be driven out of business.
Question: would you put limits on your growth, or cut back on your advertising, or raise prices, or take some other steps to keep him in business?
This raises an interesting hypothetical.
Let's suppose that there was no PCI violation, or any other ethical or legal problem with his business, but that through better pricing, service, more effective advertising, or something like that, you found yourself taking away business from him to the point that he might be driven out of business.
Question: would you put limits on your growth, or cut back on your advertising, or raise prices, or take some other steps to keep him in business?
>> I discovered this in the process of helping a new customer export their data from the old system.
If you report him, you're going to have to explain how you discovered everything you've outlined without exceeding the intended access to the system.
I see a lot of downside here for involving law enforcement. You run the risk of being accused of hacking your competitor.
If I was in your shoes, I probably wouldn't report him, but I probably wouldn't be quiet about the weaknesses of your competitor's security.
If you report him, you're going to have to explain how you discovered everything you've outlined without exceeding the intended access to the system.
I see a lot of downside here for involving law enforcement. You run the risk of being accused of hacking your competitor.
If I was in your shoes, I probably wouldn't report him, but I probably wouldn't be quiet about the weaknesses of your competitor's security.
Personally, I would not report them or call them out publicly. I wouldn't see it as my responsibility, and as far as the competitive aspect goes, I don't necessarily think that it would be advantageous in the long-run. Calling them out strikes me as a chance for some short-term gain in a way that I would personally find distasteful, if not unethical.
I agree with the sentiment of "reach our to your competitor privately, inform them of the problem, and suggest they fix it". They may be your competitor, but they probably aren't Satan incarnate, and they'll probably be grateful, and building that relationship may actually be beneficial down the road.
Look at the history with Peter Thiel and Elon Musk before they merged their respective companies. They were competitors, yes. But if either had chosen to make things personal and go into full on attack mode, they might never have merged, we would not have gotten Paypal, and Peter and Elon probably wouldn't be billionaires now. To be fair, you can argue whether or not it's a Good Thing that we have Paypal, but from their subjective perspective, it was better that they were on good enough terms to have the merger conversation.
I agree with the sentiment of "reach our to your competitor privately, inform them of the problem, and suggest they fix it". They may be your competitor, but they probably aren't Satan incarnate, and they'll probably be grateful, and building that relationship may actually be beneficial down the road.
Look at the history with Peter Thiel and Elon Musk before they merged their respective companies. They were competitors, yes. But if either had chosen to make things personal and go into full on attack mode, they might never have merged, we would not have gotten Paypal, and Peter and Elon probably wouldn't be billionaires now. To be fair, you can argue whether or not it's a Good Thing that we have Paypal, but from their subjective perspective, it was better that they were on good enough terms to have the merger conversation.
I don't know anything about PCI violations but I doubt that reporting someone would "put him out of business".
Reporting someone is a pretty weak move. A strong move would be a campaign emphasizing the superior features of your product, such as PCI compliance. Seems like a pretty easy sell, especially in today's environment when there's a security breach every five minutes.
Reporting someone is a pretty weak move. A strong move would be a campaign emphasizing the superior features of your product, such as PCI compliance. Seems like a pretty easy sell, especially in today's environment when there's a security breach every five minutes.
I would personally alert your competitor before disclosing anything the public.
As far as putting them out of business, I wouldn't be so certain of that outcome. For one thing the matter of PCI compliance is between your competitor and their payment processors. If you figure out a way to report them, their processor may just give them a chance to fix it and it will all be handled quietly. Or it could result in an audit, fines, their processor dropping them, etc. Those are all bad for the competitor, but not necessarily something that will put them out of business.
Posting on a public forum has potential to scare customers if there is such a place to post your message for your niche where "everybody" will see it. But there's a lot of ways for that to backfire as well depending on how you handle the posting of the message.
As far as putting them out of business, I wouldn't be so certain of that outcome. For one thing the matter of PCI compliance is between your competitor and their payment processors. If you figure out a way to report them, their processor may just give them a chance to fix it and it will all be handled quietly. Or it could result in an audit, fines, their processor dropping them, etc. Those are all bad for the competitor, but not necessarily something that will put them out of business.
Posting on a public forum has potential to scare customers if there is such a place to post your message for your niche where "everybody" will see it. But there's a lot of ways for that to backfire as well depending on how you handle the posting of the message.
I would only go to your competitor if you have a really good relationship with them, and you know that your report won't be taken as a threat.
If you don't, you're exposing yourself to many problems for very little upside, and my experience is that, when cornered, most people don't tend to react in a reasonable and logical manner (or even in a manner that caters to their own interests). For example, the competitor could accuse you to have came across this information illegally (whether you did or not in the eyes of the law is irrelevant: once you're faced with a lawsuit, your best likely outcome is that you will only have to pay your lawyer's bills); or, they could think you're preemptively covering your ass before starting a smear campaign against them, and beat you to the punch with accusations and threats of their own, and so on.
On the other hand, as some have pointed out, this is a good marketing opportunity for you—you just need to be careful how you use the information. I would, however, avoid making _any_ references to competitors (even indirectly by referring to “our competitors”), because you don't want to be petty, and you also don't want to ever have to answer the question “Who are these competitors of yours?” in front of a court stenographer.
You do not mention if the PCI violations could flow through to your competitor's clients; are the credit cards those that customers use to pay for the competitor's SaaS, or are they stored on behalf of customers to provide the service itself (e.g.: the way, say, Stripe stores your customers card data for you)? A breach that leaks credit card data in this case would be catastrophic not just for you, but for your customers as well—and these are consequences that have a material impact on the quality of your product over your competitors'.
From a marketing viewpoint, keep in mind that the value this piece of intel is also likely to be proportional to the sophistication of a prospective customer. A potential large client that could is more likely to be sensitive to something like PCI than small fish, and knowing that you can plant the bug in their ear that your competitors might not be as up-to-date on PCI as you are could make the difference between a sale and a missed opportunity.
If you don't, you're exposing yourself to many problems for very little upside, and my experience is that, when cornered, most people don't tend to react in a reasonable and logical manner (or even in a manner that caters to their own interests). For example, the competitor could accuse you to have came across this information illegally (whether you did or not in the eyes of the law is irrelevant: once you're faced with a lawsuit, your best likely outcome is that you will only have to pay your lawyer's bills); or, they could think you're preemptively covering your ass before starting a smear campaign against them, and beat you to the punch with accusations and threats of their own, and so on.
On the other hand, as some have pointed out, this is a good marketing opportunity for you—you just need to be careful how you use the information. I would, however, avoid making _any_ references to competitors (even indirectly by referring to “our competitors”), because you don't want to be petty, and you also don't want to ever have to answer the question “Who are these competitors of yours?” in front of a court stenographer.
You do not mention if the PCI violations could flow through to your competitor's clients; are the credit cards those that customers use to pay for the competitor's SaaS, or are they stored on behalf of customers to provide the service itself (e.g.: the way, say, Stripe stores your customers card data for you)? A breach that leaks credit card data in this case would be catastrophic not just for you, but for your customers as well—and these are consequences that have a material impact on the quality of your product over your competitors'.
From a marketing viewpoint, keep in mind that the value this piece of intel is also likely to be proportional to the sophistication of a prospective customer. A potential large client that could is more likely to be sensitive to something like PCI than small fish, and knowing that you can plant the bug in their ear that your competitors might not be as up-to-date on PCI as you are could make the difference between a sale and a missed opportunity.
Once upon a time, I actually tried to report a company out of PCI compliance. It's harder than it sounds, and there's a very good chance the PCI council will ignore your report.
As much as you feel a responsibility to the public on this you have a massive conflict of interest in this area. Sure, be nice and send your competitor an email. After that stay out of it and move on. There have been plenty of hackers who felt they were doing the right thing by informing companies of security issues they found only to have the same companies turn around and attempt to press charges on them.
All in all I'm not sure I believe in karma, but I do believe you should take the high road here. Simply reporting them doesn't fix it. But telling your competitor and reporting it as a PCI compliance issue from your company (because you do indeed have exposed credit card numbers in your possession) would be the route I would take.
Tell them and let them know you're prudently reporting it for your own sake.
Tell them and let them know you're prudently reporting it for your own sake.
Report it, and let him know too. He must be doing less than $1m/mo if it's gone on for a while, 3rd party audits are mandatory otherwise. It's a small time risk to the PCI folks anyway, they're not going to screw up his lively hood, they're just going to tell him to use a merchant processor or tokenize would be my guess.
It's 2015. If somebody is storing credit card numbers in plaintext, and then also displaying them, they deserve to be out of business. Don't make this about business ethics. In business, you are playing a chess game against all of your competitors. When one of them makes the wrong move you take them out. It's as simple as that.
As always, "Do unto others..." comes into play. Don't report them or make it public.
If anything, perform due diligence and get in touch with someone with the appropriate levels of scruples and power to take action.
Who knows? They may find out something worse about your business and respond in kind, instead of dragging your company through the mud publicly.
If anything, perform due diligence and get in touch with someone with the appropriate levels of scruples and power to take action.
Who knows? They may find out something worse about your business and respond in kind, instead of dragging your company through the mud publicly.
To me, they made the decision to put all of their clientele at risk. There's no problem with "outing" them.
Sure, if you anonymously tell them about the security loophole, will this fix future problems?
Likely not.
I say report them.
There's nothing wrong with reporting bad behavior. You're not responsible for the consequences they have to face for making those decisions.
Sure, if you anonymously tell them about the security loophole, will this fix future problems?
Likely not.
I say report them.
There's nothing wrong with reporting bad behavior. You're not responsible for the consequences they have to face for making those decisions.
Put the buggers out of business and scoop up the new prospects. Doh!
Google, Microsoft, IBM, Apple, ... wouldn't even think twice.
Google, Microsoft, IBM, Apple, ... wouldn't even think twice.
[deleted]
I don't like the idea of notifying him and then being responsible for checking in later to make sure something happened. That's not your job. You should probably report the violation and let the PCI industry handle it.
Report to whom? PCI isn't a law.
If you want to use this as a selling point when engaging his current customers, I see nothing wrong with that. If you offer greater security than he does, it's fine to point that out.
If you want to use this as a selling point when engaging his current customers, I see nothing wrong with that. If you offer greater security than he does, it's fine to point that out.
That's exactly it. There is no law being broken. The best way to capitalize off of this is to use the weakness of the competitor as a means to market yourself as a superior product. You can even use testimonials from the former customers who switched to you to further boost your own product. It doesn't sound like this competitor would be too hard to beat on merit rather than underhanded tactics.
You could also get your sales team to call your competitor's current customers and ask "How safe is your data with "X"? Are you looking for a super-secure alternative? Buy my product." Or something...
You could also get your sales team to call your competitor's current customers and ask "How safe is your data with "X"? Are you looking for a super-secure alternative? Buy my product." Or something...
Is PCI actually enforced? Intrusions at many large organizations have shown them violating PCI - eg, Sony (not the recent hack, the last one) and I've not heard about any of them being punished.
Genesco (which owns Journeys, Lids, Johnson & Murphy, Dockers Footwear) had a data breach in 2010. Visa fined them over $13 million in PCI penalties.
after the breach.
Typically any PCI certified installation that does not self-certify will have something come up in their annual review. That doesn't mean they immediately lose their certification, it means they get 'x' days to fix the the item and then they are no longer in compliance.
That's when they might get fined but if a breach occurs the fines are pretty much a given.
Fines are extra income for VISA, they typically have no clear relationship to the infraction other than that it is what VISA thinks they can bear or how much they can get away with. Fines have bankrupted companies and big breaches have led to fines that were surprisingly low. It's a lottery, for the most part.
Typically any PCI certified installation that does not self-certify will have something come up in their annual review. That doesn't mean they immediately lose their certification, it means they get 'x' days to fix the the item and then they are no longer in compliance.
That's when they might get fined but if a breach occurs the fines are pretty much a given.
Fines are extra income for VISA, they typically have no clear relationship to the infraction other than that it is what VISA thinks they can bear or how much they can get away with. Fines have bankrupted companies and big breaches have led to fines that were surprisingly low. It's a lottery, for the most part.
On the one hand, I'd be putting him out of business (and I'm well poised to scoop up those new prospects)
This is hyperbole. His customers are probably running their business, not monitoring the news for info on every SaaS they use. PCI compliance most likely isn't what keeps them there: it's friction in leaving, customer service, possibly features they don't find elsewhere. There isn't some PCI police that has a list of all their customers and will email them.
If customers are lost, it'll be a trickle. Once they identify what's up, they'll be all hands on deck to fix it, and this amazing competitive advantage you feel fell into your lap will disappear. On the other hand, maybe he'll ignore it - I promise you there will be customers that really don't care. Yeah, they should. But they won't. Your competitor will still be in business
I'd turn it into a marketing advantage, not treat it like a magic torpedo. Many of our competitors outsource their programming or are resellers of one of our competitor's services. (In our industry, whoever has your data has a list of your customers, so important to control who has access to that information) In our pitch, I tell them to ask whoever they do business with, even if it isn't us, if they outsource their operation and who controls the data. In your situation, point out that some companies in your space, without naming names, store their payment data incorrectly, and why that's bad. Then hit them with how you are PCI compliant.
Another thing to consider: if your magic torpedo scenario doesn't play out, then what? There's people out there using a provider that stores payment details insecurely. Announce it publicly, and you've just made them a target for a breach - big payday for those hackers. Muahahahah, I've killed my competitor! Maybe, maybe not, but you've also just screwed over those customers. Even if they leave that provider, when they find out the reason their credit card is being abused is due to your disclosure, there's 0 chance you'll their business, and it could have long term PR repercussions. Hell, depending on your jurisdiction, potential legal ones.
(Yes, everyone will say it's not altron's fault - it's his competitor's. It's both at that point. If I tell the world about someone I don't like who leaves their house unlocked, I'm an asshole, and don't deserve to be liked)
About the only situation where I feel this works out well for you is to contact the customers of theirs that you know, and tell them directly.
This is hyperbole. His customers are probably running their business, not monitoring the news for info on every SaaS they use. PCI compliance most likely isn't what keeps them there: it's friction in leaving, customer service, possibly features they don't find elsewhere. There isn't some PCI police that has a list of all their customers and will email them.
If customers are lost, it'll be a trickle. Once they identify what's up, they'll be all hands on deck to fix it, and this amazing competitive advantage you feel fell into your lap will disappear. On the other hand, maybe he'll ignore it - I promise you there will be customers that really don't care. Yeah, they should. But they won't. Your competitor will still be in business
I'd turn it into a marketing advantage, not treat it like a magic torpedo. Many of our competitors outsource their programming or are resellers of one of our competitor's services. (In our industry, whoever has your data has a list of your customers, so important to control who has access to that information) In our pitch, I tell them to ask whoever they do business with, even if it isn't us, if they outsource their operation and who controls the data. In your situation, point out that some companies in your space, without naming names, store their payment data incorrectly, and why that's bad. Then hit them with how you are PCI compliant.
Another thing to consider: if your magic torpedo scenario doesn't play out, then what? There's people out there using a provider that stores payment details insecurely. Announce it publicly, and you've just made them a target for a breach - big payday for those hackers. Muahahahah, I've killed my competitor! Maybe, maybe not, but you've also just screwed over those customers. Even if they leave that provider, when they find out the reason their credit card is being abused is due to your disclosure, there's 0 chance you'll their business, and it could have long term PR repercussions. Hell, depending on your jurisdiction, potential legal ones.
(Yes, everyone will say it's not altron's fault - it's his competitor's. It's both at that point. If I tell the world about someone I don't like who leaves their house unlocked, I'm an asshole, and don't deserve to be liked)
About the only situation where I feel this works out well for you is to contact the customers of theirs that you know, and tell them directly.
>> There isn't some PCI police that has a list of all their customers and will email them.
The payment processor that the competitor uses can stop processing their transactions. While I was in the PCI consulting space a few years ago, I saw many cases where small and medium sized companies ended on the credit companies black list and no payment processor would dare take their business.
The payment processor that the competitor uses can stop processing their transactions. While I was in the PCI consulting space a few years ago, I saw many cases where small and medium sized companies ended on the credit companies black list and no payment processor would dare take their business.
That's good to know. So if you get kicked out like that, will Stripe refuse your business? Also, would it be a matter of knowing who the processor was in order to report?
[deleted]
If you were to worry about wellbeing of your competitors, you would deprive your users of the fruits of fiercful competition.
Maybe.
If he advertises PCI compliance, yes, bust his ass for lying. If he doesnt - thats a gray area ethically to me.
If he advertises PCI compliance, yes, bust his ass for lying. If he doesnt - thats a gray area ethically to me.
What would Steve Jobs or Larry Ellison do?
He uses a multi-tenant database, stores CC numbers in plain-text (full 16 digits, CVV and Expiration Date), and shows that data to the user, in plain-text, at the time of payment.
I discovered this in the process of helping a new customer export their data from the old system.
I've spent days debating the ethics of reporting or making this public. On the one hand, I'd be putting him out of business (and I'm well poised to scoop up those new prospects). On the other hand, he's putting people's finances at risk and I feel obligated to say something that the public may not be able to discern.
Any advice would be greatly appreciated.