Slashdot Mirror
Credit-Card Data Breaches Drive Security Solutions
4foot10 writes with a link to a CRN article about the booming business of PCI adoption. The Payment Card Industry Data Security Standard (PCI DSS) was worked out by credit card companies as a guideline for securing customer data. As a series of high-profile customer information leaks have occurred over the last year, the business is increasingly getting lucrative for those who can keep up. "As PCI-related business begins to boom, security VARs and integrators find themselves in the enviable position of having almost too much work to handle. And there's plenty of room for the market to grow: Visa estimates that just 36 percent of Level 1 merchants (which process more than 6 million credit-card transactions annually) and 15 percent of Level 2 merchants (which process at least 1 million) have complied with PCI. Solution providers can either handle PCI-related assessments of companies' networks and then recommend solutions to address holes, or provide the remediation services after an audit, which often requires companies to implement firewalls or encryption to their networks."
The PDF isn't full of anything revolutionary, and most are just common sense data security, but it is a great starting point for securing virtually any highly confidential data.
Far too many shops don't comply with the majority (or any) of the recommendations.
Instead of coming up with all these technological countermeasures, why don't the credit card agencies simply stop offering credit without actually verifying the identity of the credit requestor? Make the data useless by itself, and people will stop trying to obtain it.
Oh, that's right, it's more lucrative to give out credit like candy, and then put responsibility for fraudulent charges on the merchants.
The biggest problems facing internet security are greed, laziness, ineptitude, apathy and general ignorance. expensive credit card hardware cant fix pebkac, all it does is make newegg raise their shipping charges.
boycott slashdot February 10th - 17th check out: altSlashdot.org
I mean come on, the linked writing has the following text
Security experts say every time a retailer ends up in the headlines for losing customer credit-card data, a PCI project gets its wings. And,as more companies look to the channel for help with securing their networks for PCI compliance, it's turning out to be a wonderful life for solution providers.
in which they link the PCI acronym to an encyclopedia site detailing what PCI as in Peripheral Component Interconnect means.
Good job.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
The standard, while a nice list of controls, has only a slight chance of helping those cannot/will not manage their risk. In the mean time it is nothing but another layer of wasteful bureaucracy (redundant?) for those who do a good job of managing their risk.
But we call all rest easy knowing that some vendor has spent $5 per IP to get a "hackersafe" badge to throw up on his webiste.
"oohhh... I didn't know Schopenhauer was a philosopher!"
Well DUH!
Don't fight for your country, if your country does not fight for you.
How can you rebill a customer without storing the CVV?
So riddle me this...
PCI rules state that the CVV can not be stored under any circumstances, period, nada, zip...
Our CC processing software company say they're working on a solution to allow recurring billing...
Our backend processing company (Nova) say they're working on a solution to allow recurring billing...
Both of the above would involve some form of submitting all CC/CVV details once at initial signup then being able to somehow *reference* that customer's account in the future without producing all those same details again.
Neither has a solution ready to go yet. We need to automatically bill thousands of people each month for services they've purchased and agreed to recurring billing for. How do we charge them next month without having their card details stored? Number/Expiration we can store, as long as it's encrypted, but CVV is a vital component and the one that is strictly forbidden.
-Between a rock and a hard place...
Like any document, it gives a smart person a starting point and a dumb person (company) a way to say they're secure when they're really not. You need a 'firewall' and an 'IDS'; devices that qualify for this can do bare ass nothing (if you can justify why it's open and why you use it, it's probably fine to have open), though you can get a good tight firewall NEED-TO-ACCESS policy (allow what you need, isolate the servers from each other, deny any). I believe you can have access to the SQL database from the outside, for example; I'm pretty sure I've seen PCI compliant sites that have a set-up where they can use Enterprise Manager or something to manage their SQL server from another location, i.e. port 1433 is exposed to the Internet BUT THEY'VE CHANGED THE DEFAULT PASSWORDS (if it has a buffer overflow etc, you're screwed). Consider that a tight policy would put that behind the firewall and say, "Fuck you. Use SSH to get behind the firewall and forward port 1433 through it."
These documents are excellent for true security engineers. For network engineers who are mostly business-oriented, they're also excellent, but only for having a way to back up your handwaving and create an insecure system that's touted as secure.
Support my political activism on Patreon.
You don't send sensitive information across the Internet period. On the client run an application that generates a unique one way hash of the transaction. This is sent to the server which performs the same hash using data stored on the server. It then sends a confirm msg to the client.
On the server the data is stored encrypted and is accessed through well defined system calls. The encryption is done by a hardware module that sits between the harddrive and the system. That way if the server is sucessfully hacked the entire database is not compromised. The hardware module provides keys to the system so there is no security data lying about the disk or in memory to be hacked. All a network sniffer can do is access a one time encrypted transaction that can not be leveraged to provide usefull information.
davecb5620@gmail.com
outsourced call center has all of your info and passwords.
The current way in which credit cards number are used is just broken. I find it amazing that it hasn't been fixed yet.h tml
Requiring that to make a purchase you have to give a shop all the information they require to make additional purchases on your behalf is just stupid.
The solution is simple, public/private key cryptography.
eg. http://jesstaa.blogspot.com/2006/06/credit-cards.
...and that is all I have to say about that.
http://jessta.id.au
...is when the credit card industry is going to grow some balls and stand up to the religious fanatics in the Bush administration who have been pressuring them to stop supplying credit card services to lawful. consenting adult erotica providers?
s ting-people/200210/msg00036.html
http://www.interesting-people.org/archives/intere
When are we going to start acting like America, instead of like some horrid Middle Eastern "Islamic Republic"?
Has anyone ever investigated the side effects of continually pouring billions of dollars into criminal industries? In essence the credit card industry is funding crime and terrorism through lax security and high tolerance of theft. It seems like this must be resulting in a phenomenal growth in all criminal industries worldwide. Using stolen credit cards as startup money to finance a boat purchase for human trafficking for example.
It simply ought to be illegal for a business to store your credit card number (or bank account number.) In fact, it ought to be possible - especially on the internet - to do business without even disclosing your credit card number. The business opens a connection to Visa, and gives your browser the info it needs to complete the transaction from your end.
If people want to bill you every month - they should send *you* an account number (which they could make easy to do, as above) and you instruct your bank/lender to send them $ every month. If you want to cancel their service, you stop paying them. "Cancellation charges", which are a major pain (and a violation of basic economic principles, to boot) should be illegal.
At this rate the problem would be more or less solved. All of the security stuff (verifying the IP address where the purchase originates, for example) could be handled by the credit card companies themselves.
Obviously businesses would be wildly opposed to this, because:
a) Many of them want to be able to bill you until they decide to stop. 90% of the time, they can extract an extra $50 per customer just by making cancelling their service a pain.
b) They want it to be convenient for you to give them money. Among other things, they really want grandma to be able to buy things repeatedly after only entering her credit card number once.
c) They want to store all of the data on you they can, on general principle.
The good and new comes from no quarter where it is looked for, and is always something different from what is expected.
Wow. I always thought that the benefits of those encrypted Seagate drives were marginal, but I'd never have guessed that you could breach them with just a few credit card numbers.
I hereby place the above post in the public domain.
I work for the PCI-certified Approved Scan Vendor (ASV) Qualys.
This is a timely article, as yesterday was the end of the quarter, and proof of PCI compliance was due. In addition, this is the first quarter that AMEX and VISA are actually fining customers if they do not meet compliance on time - starting at $5k USD per day!
As such, we have been extremely busy with the volume of customers who use us for PCI compliance. We even have a seperate service to handle this business, apart from our flagship vulnerability management product, QualysGuard. (Note: We're upgrading today, 3/31, so you will see an 'Under Construction' page for it).
My perspective on PCI compliance, from working with our customers on it, is that it is actually a crapload of work for companies to do. The standard is actually a pretty high bar. For example, a webserver that allows SSLv2 will fail you, or a VPN device that allows connections with regular DES.
It may not be a perfect standard (how do you deal with 0-day exploits that have no fix, but represent a serious vulnerability?), but it's a pretty good starting point, IMNSHO.
It just means processing through a terminal where CVV is not a requirement.
I have worked with several gateways/processors and the details depend a lot on their implementation. However typically we set up two accounts, a CVV account and a non CVV account. We funnel initial transactions through the CVV account and recurring transactions through the non-CVV accounts.
Sometimes explicit linkage is required (ie a transaction reference for the initial transaction) and sometimes there is just "trust" that the no-CVV account isn't being abused.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Making sure the systems don't raise any security scanning flags can be a pain but mostly it's a tick the box affair. (I have had to handle the SSL issue you mention. Actually disabling SSLv2 is easy, the hard part is getting all your long term clients who have been happily processing to update their side where necessary! Ultimately telling them that if they don't make their client SSLv3/TLS capable by the end of the week then they won't be able to process does the trick.)
For me the interesting part is in limiting exposure if there is a security failure. The fundamental problem is that the applications need to store credit card information to be useful, the applications need to store credit card numbers to do what they have to do (issue credits, do recurring billing etc).
The PCI documentation talks about encrypting information but in my opinion most of that is largely obfuscatory rather than giving any real security. You can have all the data encryption keys and key encryption keys you like but if the application needs to decrypt that data to do it's job then someone who compromises the application can get at it too. The best thing you can do in terms of minimising exposure is determining how long you need to keep data for and getting rid of it after that.
Any real solutions to avoid the necessity of storing card information would need to come down from the card issuers. Personally though I am not sure they are motivated to change the status quo, they must make an absolute bundle out of charging merchants for chargebacks and so forth.
Boffoonery - downloadable Comedy Benefit for Bletchley Park