A while ago I wrote this post: PA-DSS Validated Applications Published. Where I noted that our software application was on a PABP List but not on the PA-DSS List. Well we made it – it took the PCI Co a while to invoice us for inclusion on the list, but we received the invoice and promptly paid, and here we are:

* Well other then the "Validated by PA-QSA" is currently incorrect: we used K3DES.

Link to PA-DSS Validated Payment Applications:

https://www.pcisecuritystandards.org/security_standards/vpa/

Link to PABP Validated Payment Applications:

http://usa.visa.com/download/merchants/validated_payment_applications.pdf

I got out my Crystal Ball and Tarot Cards out and thought it would be fun to share some 2009 Payment Systems Predictions.

Here they are in no particular order:

Reduction of number of Stores for retailers: "The Economy" will not be kind to retailers and speciality shops in 2009. We will see stores closing; as the economy expanded retailers expanded, and the inverse will be true.  This means that companies will be looking to the expense side and looking for innovative ways to reduce operating costs that have a fast ROI and payback. This will be in systems and back-office standardization and migration from expensive legacy platforms and large maintenance agreements. Decrease in jobs means decrease in spending. Any governmental based stimulus program needs to ensure that monies provided for "kick-starting" the economy are controlled in a manner that they are spent and not saved or used to pay down existing debt.

Gift Cards: You or someone that you know will have a gift card, merchandise credit/refund card for a merchant that is no-longer is business in 2009. Gift givers will take note of this and consider giving cash rather then gift cards in holiday 2009 season.

Issuing Banks: When the "times were good" people could live with negative savings rate, and see the value of their home increase, this increasing equity plus mortgage refinances allowed people to live beyond their means. Many consumers’ behaviors will not change, and we will see a run up of credit card debt. Credit Card Issuers will be trying to mitigate this risk, and will reduce credit lines, increase fees and rates, and be more restrictive in their underwriting processes.  For some issuing banks we may see similar bailouts to that of mortgage companies and consumers are unable to pay.

Interchange Rates: There will be continued pressure by merchants to the Card Brands to lower interchange rates, and Issuers lobbing to increase them to cover increased losses on bad debt.  Alternative payment structures and card types and acceptance and Cash Discounts will be offered to consumers and driven by merchants to reduce cost of accepting payments.

End-to-End Encryption: We will continue to see a proliferation of "End-to-End" encryption options that are based on or mirror Mag Tek’s MagneSafe offering – More Terminal Manufactures will be using capable devices, and payment gateways solutions here as well. PCI Council with notice this and consider making this a requirement in a future version of the PCI DSS.

PCI Data Security Breaches: There will be data breaches of cardholder data in 2009. We will see more innovative attacks that replace those that were effective before PCI compliance was a wide spread.  Even organizations that are validated "PCI Compliant" will not be exempt. We will see attacks that adapt and change around current PCI Controls.

Mobile Payments: 2009 will be the year of push of mobile payments, with many new entries in this space and those fighting for mass acceptance. The contact-less infrastructure that has been put in place will be used and leveraged by mobile phones at card acceptor locations using Near Field Communication (NFC).

Cloud Computing / Hosted Payments Platforms: 2009 will see more applications that are typically ran in the back-office of certain types of companies to the "cloud" – the proliferation of virtualization and commodity servers allowing this, and Amazon EC2, Microsoft Azure and others including vendors that provide cloud based access to their software solutions. IT Security Buffs and PCI Auditors will debate PCI and Cloud Computing.

The Internet Crime Complain Center (I3) released a memo on December 15th 2008 – titled Preventative Measures:

“Over the past year, there has been a considerable spike in cyber attacks against the financial services and the online retail industry. There are a number of actions a firm can take in order to prevent or thwart the specific attacks and techniques used by these intruders.”

There are 12 Recommendations here, 11 of those, that in all honestly, should not be new to any one addressing IT Security or PCI Compliance – I can map each of these 11 to a PCI requirement:

• Recommendation 1,2,4,6,8 : maps to PCI 2.2.x   “Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.”

• Recommendation 3: maps to PCI 6.5.x  “Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes”

• Recommendation 5: maps to PCI 7.2.x “Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.”

• Recommendation 7: maps to PCI 8.5.13  “Ensure proper user authentication and password management for non-consumer users and administrators on all system components”

• Recommendation 9,10: maps to PCI 1.3.x “Prohibit direct public access between the Internet and any system component in the cardholder data environment.”

• Recommendation 11: maps to PCI 1.2.1  “Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.”

The last one is a little different and or not as common as the items above:

Recommendation 12: Ensure your HSM systems are not responsive to any commands which generate encrypted pin blocks. More specifically, HSMs should not accept commands that allow plain text PINs as an argument and respond with encrypted PIN blocks.

HSMs are normally used to verify Personal Identification Numbers (PINs), generate PINs used with bank accounts and credit cards, generate encrypted Card Verification Values (CVVs), generate keys for Electronic Funds Transfer Point of Sale systems (EFTPOS), and generating and verifying Message Authorization Codes (MACs). These systems, if accessed by an unauthorized intruder, can provide the attacker the ability to discover the appropriate PIN number for a corresponding credit or debit card. Therefore, in an effort to prevent this, HSMs should be configured to disallow “in the clear” PINs as an argument for performing its tasks.

This recommendation discusses configuration options with Hardware Security Modules or HSM’s. There is a attack that allows an attacker to derive how a PIN is encrypted if the HSM Allows for functions that allow a Clear PIN as an input an attacker can send various clear PINs and analyze the output from the HSM.

At one of our acquiring clients we communicate with a Thales 8000 HSM. The functions that we are are for PIN Translations for Debit/EBT Transactions. The functions that we use for this do not involve a clear pin, we receive an encrypted PIN Block from the Point-of-Sale and PIN-Pad that we translate to a different PIN Block under a different encryption key to the Debit/EBT Networks and/or providers.

Looking at the “Thales — Console Reference Manual” – I see this option:

Select clear PINs: Yes or No

This enables the clear PIN support via host commands „NG? and „BA?. Authorised state is
a requirement for these commands to be processed by a host application.
Note: This is a security risk unless precautions are taken at the host.

The Manual states that this is clearly a bad thing:

So for Requirement 12 – Make sure that you are not using any “Clear PIN’s” and any function that allow “Clear PIN’s” as an argument are not enabled.

Dr Anton Chuvakin points us to NEWS FLASH! Titanic Was Compliant a post on The Guerilla CISO located here.

The theme of the post is that compliance is not security. Do yourself a favor and read the full post for yourself. It is about someone questioning how a failure could occur "even after smart people put their heads together and try to deal with the problem before facing a crisis" The example of the RMS Titanic is perfect:

I told her that the problem here was that the Titanic indeed did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes and in the size and design of ships of this kind.

…

So, the bottom-line was that when the Titanic was reviewed by the safety accountants, they took out their check-list and went over the ship with a fine tooth comb. When the day was done the ship fully met all the safety criteria and was certified as safe.

Did you get that ?  The Titanic was compliant to the current safety standards of the time.

Think of this when you are reading through your SAQ or PCI DSS Audit Procedures – and understand that the PCI Standard is a baseline of controls to follow to protect cardholder data, you may need to go above and beyond these. Don’t feel that you are "secure" because you are PCI compliant, and don’t be surprised that PCI compliant entities can still have security incidents.  Your Risk Management program and practices should include addressing compliance, but compliance should not be your goal for "security."

innerfence has developed an iPhone App called the Credit Card Terminal.  It is a thin application that acts as a front end and uses an Authorize.net Merchant account using the Authorize.net API over SSL. Looks pretty neat and a useful option for mobile acceptance of credit cards.

Looks like innerfence is a Authorize.net reseller, since you can use any authorize.net merchant account – I suggest you shop around the the best rates, theirs appear to be a little high.

I’ll put this in the "Why didn’t I think of that ?" category.

EDIT:  Check out this link to the innerfence blog where there is a video on the app, and its integration to another iPhone App – Ring It Up Point of Sale.

For fun I decided to develop a TwitterLogListener class for the jPOS Framework. It leverages JTwitter – the Java library for the Twitter API from Daniel Winterstein. With this, you can send alerts and/or messages to a twitter account for monitoring from a jPOS application.

You need to configure a TwitterLogListener in your logger:

<log-listener class="org.jpos.util.TwitterLogListener">
 <property name="twitterUsername" value="paymentsystems" />
 <property name="twitterPassword" value="SuperSecretPassword" />
 <property name="tags" value="twitter" />
 <property name="prefix" value="[jPOS]"/>
 </log-listener>

And you need to Log an event with a ‘twitter’ tag:

<script name="test" logger="Q2">
     import org.jpos.util.*;
         for (int i=0; qbean.running(); i++) {
              LogEvent evt = log.createLogEvent ("twitter");
              evt.addMessage ("This is a Twitter message test from jPOS! " +   i);
              Logger.log (evt);
	           Thread.sleep (10000L);
       }
</script>

Look at the messages in a twitter account: http://twitter.com/paymentsystems

For more details on this see this post: http://is.gd/eDbI

I’ve configured my blog to “tweet” my posts to this Twitter Account. So If you are a twitter user and want to be notified the go ahead and follow paymentsystems on Twitter.

I was reading an article on BloggingStocks about new proposed tax-cuts :   The key point from this was that any tax cuts or stimulus plans would probably be used to pay down debt or  "saved" at the bank and not used to stimulate the economy like these programs are intended to do, which is spend.

The Bush tax rebate happened before the recession started to bite. Many people were willing to spend the money the government sent them. But, in much less than a year, sentiment has changed tremendously. Business and individuals are showing that any money they bring in goes to pay debt or increase savings. It is not clear how that helps the economy quickly. As a matter of fact, given the overall reluctance to spend, it may not help the economy at all.

 

Rather then a check or a direct deposit ?  What would happen if you got a Pre-Paid Stimulus Payment Card, you would likely spend it, rather then deposit it ?  The TV Coupon Converter program appears to be a good model for this.

Once upon a time there was a great forum for PCI related questions and discussions, it was called PCIAnswers.com.  This site was shutdown and merged sometime ago into the The Society of Payment Security Professionals (SPSP) – which was an attempt to consolidate everything to their site. Unfortunately the forums module of the software that ran this site was of poor quality, the users of the forums declined and/or moved to use:  the PCI_Standards Yahoo! Group or the PCI Knowledge Base Forums instead.

I received an email over the weekend that the SPSP has decided to move its discussion forum: The forums have been moved (back) to http://forum.paymentsecuritypros.com/    <– As a CPISM/A I prefer this site