Poor old CardSystems Solutions
Both companies said that they would no longer do business with the ACH (automated clearing house). MasterCard has given CSS until the end of August to demonstrate compliance with MC’s standards or face the same cutoff.
It doesn’t look good for CardSystems’s long-term survival unless it can pull a rabbit out of the proverbial hat—and soon.
You’d think that just because CSS screwed around with hundreds of thousands of credit-card accounts, that the credit-card industry would enforce the normal penalty of a wrist-slap and continue business as usual. Or at most, impose some token monetary penalty. Not this time. The industry pulled the plug.
This sends message(s) to the entire ACH infrastructure. The first is “We’re serious.”
Never before has an ACH been blackballed for security malfeasance. Never. This kind of action by the credit card companies is groundbreaking in its scope.
The second message is “Wake up, you could be next.”
All of the ACH players have to be nervous right about now. The 12-step program mandated by the Payment Card Industry Data Security Standard, which was introduced late last year, is about to be enforced by the card companies.
The standard means that “best practices” for IT, not just “acceptable practices” have to be used by anyone in the supply chain.
That means an ACH has to spend money for IT upgrades and revisions, which will standardize the IT practices for all of the card-issuing companies. Some of the ACHs won’t be ready to comply so fast. They’ve been dragging their feet on this, hoping it will go away. It won’t.
The Lesson
In a way, CSS did everyone a favor. It showed how flawed our current financial IT infrastructure is in everyday practice.
Microsoft plans to buy secure messaging company. Click here to read more.
No one ever heard of CSS before the problems arose. You won’t hear about many places that have even worse security policies in place until something goes wrong and they get caught with their firewalls down.
The root problem of all of this is that our current financial system confuses identification with authorization. A social security number was always envisioned to be something that was for SS purposes only, not as something that served as an identification/authorization token.
But Federal law has changed. USC 405 [C] and subsequent sections state that it’s just fine for any state or government agency to require an individual to provide their SSN: “[…] for the purpose of establishing the identification of individuals affected by
such law […].” Pretty clear.
Some businesses have come to rely on the SSN as a unique identifier for someone (and by inference a token for authorization), and this will have to stop if we are ever to have a secure financial infrastructure.
This may be hard to do, but we will know that a real change has happened when this kind of screw-up happens in the future and nobody really cares because it won’t adversely affect them.
Larry Loeb was consulting editor for BYTE magazine and senior editor of WebWeek. He serves as a subject matter expert for the Department of Defense’s Information Assurance Technology Analysis Center, and is on the American Dental Association’s WG-1 and MD 156 electronic medical records working groups. Larry’s latest book is “Hackproofing XML,” published by Syngress (Rockland, Mass.). If you’ve got a tip for Larry, contact him at [email protected].
Check out eWEEK.com’s for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s Weblog.
