The first item lists a summary of changes we should expect in PCI 1.2 which will be released in October 2008
Changes to the PCI DSS include clarifications and explanations to the requirements, with these clarifications offering improved flexibility to address today’s security challenges in the payment card transaction environment
The following are the main highlights:
WEP is no longer allowed and is being phased out
Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x) using strong encryption for authentication and transmission.
New implementations of WEP are not allowed after March 31, 2009.
Current implementations must discontinue use of WEP after June 30, 2010
Use of anti-virus software applies to all operating system types
Flexibility to the patching requirement by specifying that a risk-based approach may be used to prioritize patch installation
Various re-wording of items for clarification purposes.
Get the details here:
The Payment Card Industry Data Security Standard (DSS) v 1.2 will replace the DSS v. 1.1 on October 1, 2008. This Summary of Changes document provides an overview of the significant differences between the two versions.
"A Perfect Fit - Understanding the Interrelationship of the PCI Standards,” to be held on Thursday August 21, 2008 at 9:00 a.m. EDT and a second session the same day at 7:30 p.m. EDT.
Webinar participants will discover:
• How the PCI DSS, PA-DSS and PED Security Requirements interrelate; • Why merchants should know about PA-DSS and PED; • Why incorporating PCI standards is your best approach to protecting cardholder data; • Using PCI standards as a model for data security.
ATM, Debit & Prepaid Forum is a card and payments-based event in its 16th year, focusing on three distinct market segments (ATM, Debit & Prepaid), with an added track and additional focus on emerging payments, in one comprehensive program, designed for C-level executives from banks, financial institutions and non-traditional bankcard issuers.
ATMs and the Future of Cash
Surcharge-Free Networks
ATM Service Delivery
Debit Rewards
Fraud Prevention
Debit Product Development
New Benchmarking Research
Prepaid Innovation
Reloadable Prepaid Cards
Debate on the Size of the Prepaid Market
Mobile Banking and Payments
Serving the Underbanked and Youth Market
Alternative Payments
I have a few invitations that I can send out to the show - these are special invitations that offer a discounted registration fee , please email me at david@paymentsystemsblog.com before August 18th.
There seems to be a few companies that I’m continuously hearing more and more about in the interwebs. One such company is one called Revolution Money. Revolution Money has two main products Revolution Money and Revolution Exchange:
The RevolutionCard eliminates costly interchange fees for merchants while simultaneously providing consumers with enhanced PIN-based security, identity protection, and periodic merchant discounts and incentives. MoneyExchange offers an easy and secure way to send and receive money online between accountholders for free.[1]
Revolution Money comes at an interesting time with many merchant concerns of interchange fees:
The card’s chief advantage to merchants is its acceptance cost—0.5% of each purchase amount—which compares favorably to bank card discount fees at a time when merchants are disgruntled about the cost of accepting cards. [2]
The main challenge however with any new payment card/technology is merchant acceptance and cardholder issuance. This is true for a myriad of reasons, new terminals for merchants, integration of a new payment types of message formats to terminals, Point of Sale Systems, Payment Switches, and consumers to acquire another payment card and incentives to use that over the other bits of plastic that compete for their wallets, billfolds purses and handbags. But it appears that Revolution Money is planning for a million merchants by year end.
(June 20, 2008) Nine months after its official launch, Revolution Money Inc.’s PIN-secured credit card is being accepted at 150,000 merchants, a number a top executive at the St. Petersburg, Fla.-based alternative-payments provider says will reach 1 million by year’s end.[2]
I think that the bottom line is that this "Revolution" is set to challenge the ways of the current payment processors and payment networks, and add a new layer of competition, or at least the pressure of competition on interchange fees, especially for merchants that are currently resorting to cash discounts if a payment card is not used.
There seems to be a few companies that I’m continuously hearing more and more about in the interwebs. One such company is one called Obopay. If I had to describe it in one sentence, it would be that Obopay is like Paypal but with using your phone, instead of your email address/Paypal account. Obopay has the tagline - "Money Transfer by Cell Phone or Web".
I signed up for an account today, received a text message to my cell, activated my account, and currently I’m in the process of waiting to confirm my bank account with a series of micro deposits, that I need to enter into Obopay to confirm my bank account.
Right now I can see this very useful, especially when I end up at a merchant or am at a vending machine and dry out of cash and cannot use plastic. I borrow some money, text a message to my friend, and everyone is happy.
The fee to transfer money recently increased from .10 to .25 a transaction, but note that this is for any transaction amount, there is not a transaction fee + % fee of transaction amount model.
I really don’t know how many merchants currently accept Obopay, but I suspect that this will be a popular payment option to certain market segments of consumers. Especially that it can be linked to either a bank account or credit/debit card.
After my bank account is confirmed I plan to use this when I can.
1) So give it a try your self: click the link below to get an account:
2) And try a test transactions by sending me $1 below. :)
Now the latest perpetrator is an organization that:
is the global, not-for-profit leader in educating and certifying information security professionals throughout their careers. Recognized for Gold Standard certifications and world class education programs.
So when paying for my annual dues for a security certification: I see the following prompt for my "Security Code"
PCI 3.3.2:
"Do not store the card validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions"
Q. Can merchants store my 3-digit code? A. No. To ensure information security, all merchants are prohibited from storing the 3-digit code in any format whether on paper drafts, receipts or electronically.
Avoid CVV2 Storage. All merchants are prohibited from storing CVV2 data. When asking a cardholder for CVV2, merchants must not document this information on any kind of paper order form or store it on any database.
A few months back I went to https://www.dtv2009.gov/ and registered for my two $40 TV Converter Box cards.
Congress created the TV Converter Box Coupon Program for households wishing to keep using their analog TV sets after February 17, 2009. The Program allows U.S. households to obtain up to two coupons, each worth $40, that can be applied toward the cost of eligible converter boxes.
I wanted one just to have, and to help two retailers each get $40.00 of revenue as a part of an economic stimulus plan … and also because we implemented acceptance of these cards in our payment system, OLS.Switch. You can read about it here, but basically we needed to add the "589732" Bin range to our switching logic/parameters, and create a rule that these transaction must have an amount of $40.00 and then we just switch them out to MasterCard. So with cards in hand, and actually realizing yesterday that they actually expired on August 6th and I only had that day to use them, I ran a few errands over lunch and made my way to a Wal-Mart and a Best Buy.
Finding the product on the shelf was easy. Wal-Mart had the RCA model for $49.99. I had the cashier in the electronics department perform the checkout (assuming that they would have been better trained then the front of the store staff) The gentlemen that was my cashier was given his first opportunity to ring this type of up though. He didn’t know what to do when presented with the card, so he asked for help from another associate: "Oh - you run that just like a credit card, and have him sign for it," and then he needs to pay the difference." I was in business and had me first TV converter box. The Sales receipt showed I used an Electronic Voucher for $40.00 and provided the approval code and last 4 digits of my TV converter card. I asked for my card back, and was given a funny look, like you know you cannot use this again right ? — so the other associate told my cashier that they can either return the card or most of the time they just toss it (The card does contain my Name in its Track 1 Data)
The Best Buy experience was a little smoother, find the Insignia TV Converter box, bring it to the front, give the card, pay the difference, and I’m on my way. Although the girl at Best Buy trashed my 2nd TV Converter Card — At least I have one left. So does any body have any old TV’s I can use these on ?
NEW YORK - The Department of Justice announced Tuesday that it had charged 11 people in connection with the hacking of nine major U.S. retailers and the theft and sale of more than 40 million credit and debit card numbers.
Under the indictments, three Miami, Florida, men — Albert "Segvec" Gonzalez, Christopher Scott and Damon Patrick Toey — are accused of hacking into the wireless computer networks of retailers including TJX Companies, whose stores include Marshall’s and T.J. Maxx, BJ’s Wholesale Club, OfficeMax, Barnes and Noble and Sports Authority, among others.
The three men installed "sniffer" programs designed to capture credit card numbers, passwords and account information as they moved through the retailers’ card processing networks, authorities said.
I’ll just say it; I’m proud of our release cycle for OLS.Switch.
It has been my experience (YMMV) both first hand running an authorization host/switch (issuing and acquiring) and as an IT Security Auditor and QSA - that either Core Banking applications or Payment Switches fall into one of the following when it relates to upgrades, changes, or security updates:
"The Vendor set it up, we don’t touch it"
"We don’t patch it because we are afraid"
"We cringe everything we need to install a new release of the software"
"Last time we did an upgrade, we had x amount of downtime"
"It all goes smooth like clockwork"
During Vulnerability Assessments and Penetration Testing on the Internal Networks that I performed– My observations from an operating system, database and application perspective - these systems are typically not keep current or run on a platform that the organization is not very familiar which and relies on outside support. The application was not cohesive to the rest of their operating environment: systems, technologies, and procedures.
Installing new releases of our software (or rather our clients installing releases of new software) is something that does not make me cringe. (and I used to not sleep very well in the past) At least one of our clients seems to agree as well. (See Andy’s "A very simple platform to support")
We just rolled out a new release that was quite large (see Flexible Spending Accounts (New Initiatives, Part 3) and had changes that impacted pretty much every transaction path due to partial authorization and credit reversal support, and required heavy regression testing. Our agile based SDLC is a big help with this, we have very iterative development processes and frequent testing which also means less large bulking updates that break everything.
Another success factor is our simplicity of upgrading our program code and binaries. It is really as simple as:
Stop the OLS.Switch Service or Daemon
create a backup copy of the directory or file path where OLS.Switch is installed
Start the OLS.Switch Service or Daemon
Perform test transactions and monitor.
The Back-Out plan is to stop the service and revert back to the backup copy.
Further, System Implementation Design can have a big impact on Up-time; we run multiple independent application servers behind load balancers, that allows us to gracefully stop an application - which stops accepting new transactions when finishing to process those in its queue, and the load balancer stops routing transactions to this application server. Allowing an upgrade to be made while other application servers are still processing transactions. Uptime, not system uptime, but uptime processing transactions doesn’t have to suffer for "scheduled maintenance", or security related patches and reboots.
I think we have a low-risk upgrade/update path that our clients are very comfortable with - So in 7 months into the year - we have had a dozen releases to add additional functionality, address endpoint changes, and implement new transaction types.
The Electronic Transaction Association (ETA) has a good write up on the Merchant Card Information provisions that are part of the American Housing Rescue and Foreclosure Prevention Act of 2008 (HR3221)
"The major outlines of the requirement are clear: Acquirers must report to the IRS the aggregate dollar amounts of credit and debit card transactions for each merchant that has more than $20,000 in transactions and more than 200 transactions per year. Reporting will have to be done by taxpayer identification number (TIN). In certain cases, acquirers may also have to subject merchants to backup withholding."
See the ETA article here for more info and a summary of the final legislation here.
Looks like the burden of this is mostly on Third Party Processors and Acquring Banks who settle transactions directly with the Card Brands, also note that cards types also include ACH, Paypal. and goes into effect at the end of 2010.
Payment Systems Blog covers payment systems including security, development operations and payments news by David Bergert, CISSP, CISA, CPISM/A, CompTIA Security+ and former QSA (PCI Auditor)