There is a new Mastercard which has LCD screen and keyboard. It looks like the plastic becomes smarter and closer to POS terminal in its functionality which I guess will bring new security issues...  

I just received the PCIP Certificate from the PCI SSC!
Main difference from PCI ISA certification is that PCIP is personal certification while PCI ISA is linked to particular employer...

I would like to update you on most notable news from the PCI 2012 community meeting which took place in Orlando, Florida. 

1. There were no announcements regarding any major changes in either PCI DSS or PA-DSS, but there is a tendency of expanding these standards into the new areas such as Tokenization, Mobile Payments, and P2PE (see below).

2. Tokenization guidelines will become a standard in near future which means the rules around tokenization must be followed and any token implementation must be assessed by auditors. It is still unclear whether it is going to be separate standard or part of the existing one such as PCI DSS. The standard will cover all aspects of tokenization such as token generation, token storage (token vault), usage, etc. Final delivery of the standard: 2013-2014.

3. Mobile Payments
  - The Mobile payments solutions are going to be divided into 3 major categories with several sub-categories – based on different technologies and hardware/software configurations. For example, smart phone based solutions fall under 3rd category. The idea is to gradually release guidelines for each and every category/sun-category, and eventually create a mobile payments standard, so most probably, the mobile payments guidelines eventually will become a standard - similar to Tokenization. There were no timelines provided for the future guidelines or standards.

- New PCI Mobile Payment Acceptance Security Guidelines for Developers were released during the meeting.

4. P2PE
- Next Steps:
  The next step is releasing the Hybrid P2PE Requirements (there is an existing draft), and the next one is going to be software P2PE. No dates were provided.

- SAQ-P2PE-HW: I don’t know if you have noticed but there is new SAQ-P2PE-HW (Self-Assessment Questionnaire for Hardware/Hardware P2PE) available on PCI website since June. It still cannot be used because there are no listed PCI P2PE solutions yet. Once the P2PE solutions listing is published on the PCI website, merchants that implement PCI approved P2PE solution will be eligible to complete special SAQ which is supposed to be “easier” than regular one.

Note: this is still only applicable to merchants that are eligible for SAQ. Others will still go through the regular QSA assessment.

5. New PCIP (PCI Professional) certification program was just launched (in September). The idea is that each organization would have PCIP-certified employees who understand the PCI and help to maintain PCI compliance. The difference between PCI ISA and PCIP is that PCI ISA is linked to specific employer while PCIP is a personal certification.

Criteria:
All candidates - training course and exam;
CISSP holders - only exam;
PCI ISA holders - no training or exam, can be earned automatically (I signed in already).

Visa to launch its "Visa Merchant Data Secure with Point-to-Point Encryption" in 2013:

• Minimal impact to payment processing systems. Merchants and acquirers ca adopt point-to-point encryption with ease because of the minimal impact to existing payment systems. To make the transition as easy as possible, Visa will also offer a "format preserving" option, enabling merchants to integrate point-to-point encryption using a 16-digit encrypted value with their current systems.
• Consistent, open encryption standard. Visa's encryption solution relies on the same Triple Data Encryption Standard (TDES) and Derived Unique Key per Transaction (DUKPT) key management that are used to encrypt PINs today. This provides a consistent framework for managing keys and minimizes the impact of merchant system updates.
• Multi-zone encryption. Visa's solution allows for encryption and decryption in multiple zones, providing merchants and acquirers flexibility in how to deploy encryption within their unique environments. Multi-zone encryption can facilitate routing to multiple endpoints, if the merchant is using multiple processors, consistent with how PIN encryption is managed today.

I think this is confirming the fact that -- despite all the PCI efforts -- P2PE (whether it is PCI approved or not) is the only technology that can provide a real protection for magnetic stripe payment cards.
No more technical details are available at this time...

Eddie Lee demonstrated at DefCon XX how the RFID credit card data can be stolen and used to run payment transaction by replay attack with regular NFC enabled cell phone (and of course loaded with specially crafted software):
    "NFCProxy is a new tool (being released at DEF CON 20) that allows you to proxy RFID transactions using Android phones. NFCProxy can record and replay RFID transactions from the perspective of the tag or the PCD (proximity coupling device). NFCProxy is an open source tool/framework that can be used to analyze 13.56?MHz RFID protocols and launch replay (and potentially man in the middle) attacks. You can even use NFCProxy as a virtual wallet by storing previously scanned RFID enabled credit cards and replaying them later at a POS (point of sale) terminal. No fancy equipment needed…just two NFC capable Android phones running ICS (one with a custom rom). Owning RFID enabled credit cards just got easier!" 
    I watched the presentation and it was very impressive. Personally, I don't care because I still do not have any card with RFID chip. However, according to Forbes, there are "100 million contactless credit cards currently in circulation". Pretty good market if someone decides to exploit this vulnerability.
    One detail is still unclear though: what specific types of card readers and protocols versions are vulnerable? Is it some 10 years old refurbished retired device purchased on eBay that was used in the demo, or it was PCI PTS certified one which is eligible for "secure" deployment at merchants' stores? I sent this question to PCI SSC PTS group. I will try to obtain these details from the author and will keep you posted.

This guy -- ZonD Eighty -- managed to trick the Apple app store payment system (by using the alternative payment website -- in-appstore.com -- and fake certificates) in order to get for free the services which are normally supposed to be paid through the Apple app store. Here is how it works (pretty simple!):

"First
Sign off your appleID in Settings->Store->Tap on your appleid->Sign Off

Second
Open this page into your iDevice. Install these certificates (just tap on links): First, Second. The order of installing is very important! Install first certificate first, second - second.

Third
Go to application where you want to buy in-apps, and make attempt to buy something. Tap "Cancel" on "Do you really want to purchase?" window.

Fourth
Open Wi-Fi settings on your iDevice and tap arrow on the right of your Wi-Fi network. Remove all data from DNS field and set it to this IP address: 94.228.221.10, 91.224.160.136(more to come)

U're done!Go to your application and try to buy something!" 

I have received the PCI ISA certificate. At least I will be able to speak with QSA on their language.

If you are not familiar with CWE/SANS Top 25 Most Dangerous Software Errors - it is very good list of application security vulnerabilities. However, are all these Top 25 errors in reality applicable to all types of applications? Let’s take some hypothetical software although created for specific area and using specific technology - for instance, simple retail store standalone point of sale application code written as .NET Windows Forms - and review how these Top 25 are relevant to our example.

First, let’s remove all issues that without a doubt related to WEB applications only (and therefore, irrelevant to our Windows Forms application):

[4]      Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
[9]      Unrestricted Upload of File with Dangerous Type
[12]    Cross-Site Request Forgery (CSRF)
[22]    URL Redirection to Untrusted Site ('Open Redirect')

Then, let’s remove from the list all the errors that cannot affect the managed framework such as .NET - we have another 4 errors to exclude:

[3]      Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
[16]    Inclusion of Functionality from Untrusted Control Sphere
[18]    Use of Potentially Dangerous Function
[20]    Incorrect Calculation of Buffer Size
[23]    Uncontrolled Format String

Now, let’s review the one more group of errors which theoretically can be applied to our application's technology and functionality, but it would be either impractical to perform such attacks or/and there are no real world examples:

[1]       Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
SQL injection was invented for attacks on websites. Although you can theoretically still inject the SQL statement through Windows Forms GUI, such attacks are rare, and Windows Forms GUI controls are usually more restrictive than WEB controls. Also, the scale of single workstation cannot be compared to the website database which potentially can contain data of millions of users.

[2]       Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
I don’t think this is relevant to the desktop application since normally the desktop application user already has access to the OS functions (can run another process). Therefore, the same OS functionality is available for application and user.

[13]     Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
It looks like this error mostly affects web based applications, although the description does not say so.

[15]    Incorrect Authorization
Even though this issue theoretically can be applied to any technology and business area, I could not find any description or example which would prove that it is relevant to our case.

So we have only 12 remaining errors that are applicable to our application.

However, before forming the final list, I would change the priorities because different issues have different effect in our specific area (remember - retail store point of sale application), and the order does not necessarily match the original order defined by CWE/SANS. So this new list is sorted according to the prioritization which mainly takes into consideration the security standards affecting this kind of software - PCI DSS, PA-DSS, and PCI P2PE - as well as common security design principles for retail financial software. (The customized list still has the old numbers in [] for reference to the original CWE/SANS Top 25.)

Top 12 Most Dangerous Security Vulnerabilities in Standalone Point of Sale Application

1.         [8]        Missing Encryption of Sensitive Data
2.         [25]      Use of a One-Way Hash without a Salt
3.         [19]      Use of a Broken or Risky Cryptographic Algorithm
4.         [7]        Use of Hard-coded Credentials
5.         [14]      Download of Code Without Integrity Check
6.         [11]      Execution with Unnecessary Privileges
7.         [5]        Missing Authentication for Critical Function
8.         [6]        Missing Authorization
9.         [10]      Reliance on Untrusted Inputs in a Security Decision
10.       [17]      Incorrect Permission Assignment for Critical Resource
11.       [21]       Improper Restriction of Excessive Authentication Attempts
12.       [24]      Integer Overflow or Wraparound

In a similar way, the original CWE/SANS Top 25 list can be customized for other particular business and technology niches, such as, for example, game application for mobile device, but it is out of scope of this post and this blog. 

PCI Security Standards Council just released "customized fact sheet" - guidance for merchants on how to securely implement mobile payments. According to this document called "Accepting Mobile Payments with a Smartphone or Tablet" (but for some reason referenced in press-release as "At a Glance: Mobile Payment Acceptance Security"), Point-to-Point Encryption solution -- validated and certified by P2PE QSA using recently launched PCI P2PE assessment program, and listed on PCI SSC website -- "may help you in your responsibilities under PCI DSS" and "leverages a mobile device’s display and communication functions to secure mobile payments". The only diagram in this document, which illustrates the architecture of mobile payment solution, shows P2PE solution provider accepting and processing merchant's mobile payment transactions.