PCI SSC just released updated and finalized requirements for hardware/hardware Point-To-Point Encryption solutions. It is still unclear when software requirements will be available. The PCI P2PE validation program is supposed to be launched officially after the first P2PE QSA training on May 11-13.

There are many questions about Microsoft's December 29, 2011 Out-of-Band Security Bulletin (MS11-100). Note that only ASP.NET is affected so you should not worry unless your machines are running website on IIS with ASP.NET. 
More information can be found here

BEAST stands for Browser Exploit Against SSL Tool.
This is variation of Man-in-the-middle attack invented by Juliano Rizzo and Thai Duong.
Here is the results of my brief research on BEAST.
Even though the detailed scenario of the attack apparently is not published by their authors, there is some information and area experts reviews available online so I could reconstruct the picture from several puzzles.
The most important outcome – the attack is unable to compromise the custom client/server application communication as it is aimed against browser client/WEB server communication only.
It is using WEB vulnerabilities and must inject malicious java script code into the client browser in order to initialize the attack. Therefore, it affects websites only and does not affect custom software using SSL.

Workarounds/Mitigations that are known today:

Using non block (stream) ciphers such as RC4 instead of standard default block ciphers such as AES.
Disadvantages: 
  o   strongest ciphers (such as AES) mostly  using blocks, and stream ciphers (such as RC4) may have their own weaknesses
  o   streaming ciphers may not be supported by all browsers/servers

Using TLS 1.X and higher (eliminating using SSL 3.0 and TLS 1.0 which are found vulnerable for the attack)
Disadvantages:
  o   TLS 1.X is not widely used and therefore not proven enough;  
  o   TLS 1.X  is not supported by all browser versions therefore after server will be reconfigured some clients using old browser versions may be unable to access it.

The two counter measures described above require WEB server reconfiguration that would possibly make some clients unable to access the websites. Before anything is done, it should be thoroughly  researched and tested.

Microsoft promised to release a Windows OS patch that blocks it (IE browser uses Windows SSL implementation). 

I would like to update you on most important topics that have been discussed during 2011 PCI SSC annual meeting in Scottsdale, Arizona.

P2PE

The most (and almost the only) important topic was, as everyone expected, P2PE (Point To Point Encryption).

Recently, just few days before the meeting, the Council released a big document which defines requirements for Hardware/Hardware P2PE.

“Hardware/Hardware” means that both encryption and decryption are being performed by hardware modules approved by FIPS 140-2 Level 3, PCI HSM or PCI PTS certification programs (normally - pinpad device at the client point and HSM appliance at the switch end).

The document and its outcomes have been widely discussed during the meeting, and here are several important points that I noticed:

·         Hardware P2PE, when implemented according to SSC requirements and properly certified, is supposed to significantly reduce the PCI DSS certification scope, meaning reducing the merchants PCI costs, particularly – may eliminate additional firewalls installations and quarterly penetration tests. Therefore, merchants are supposed to be financially stimulated to look for P2PE encryption solutions. Technical detail: This is applied mostly to Hardware encryption, also with pinpad content signed by the vendor in a way that it would be impossible to alternate it, which provides functionality of internal “firewall” isolating device middleware from the rest of merchant’s network.

·         Final release of the requirements and most important – test procedures – will be published in Q4, or by the end of 2011, which means that if you want to be the first in this race – the design and the code should be done by the end of this year.

·         There will be special certification program introduced for P2PE, auditors will have to be certified as “P2PE QSA” in order to be able to perform such assessments. The timeline for certification program finalization and QSA training – Q1 2012, but no one believes it is going to happen in Q1 and most probably it is going to be Q2 or even later.  I talked to several QSAs and all of them have no clue about the program details, even not all of them intend to be trained for it in near future. If you want to be in first wave of certified P2PE solutions, most probably, you will have to stick with the “big” guys as they are the only ones who commit for everything from SSC as soon as it comes to live.

·         Even though major focus is being made on Hardware/Hardware P2PE as almost ultimate solution for the PCI compliance, software P2PE will still remain a valid option. There is a plan to release detailed requirements regarding SW P2PE as the next step (though no timelines were provided). This will include definition of HW P2PE with SW key management.

PA-DSS

There is interesting tool provided by PCI SSC that allows you to determine whether application is eligible for PA-DSS assessment. This is simple questionnaire which is available online. If one of the answers is YES, the application should not go through the PA-DSS validation.

Please take a look – there are interesting questions.

For example, according to question #8, if the product is DLL that requires third party hosting application, such software might not be validated through PA-DSS while any POS that uses it should be certified either through PA-DSS or PCI DSS process.

Mobile

Currently, according to the guidelines recently released by the PCI SSC, most mobile payment applications do not qualify to be PA-DSS compliant. There will be a draft guidance on PA-DSS for Mobile devices released in Q4 2011.

ISA

There is interesting program for companies that want to perform their own internal PCI DSS like assessments – it is called ISA (Internal Security Assessor). The company that wants to participate just needs to enroll to this program and send people for training.

Links:

https://www.pcisecuritystandards.org/documents/nb59Y8Qqv/P2PE_Hardware_Solution_%20Requirements_Initial_Release.pdf
https://www.pcisecuritystandards.org/documents/Applications_Eligible_for_PA-DSS_Validation.pdf
https://www.pcisecuritystandards.org/documents/statement_110624_pcissc.pdf
https://www.pcisecuritystandards.org/training/isa_training.php

PCI Security Standards Council recently issued press release clarifying position of the Council on mobile payment applications. According to the special “update on PA-DSS and mobile payment acceptance applications”, PCI SSC won’t allow payment applications developed for mobile devices such as iPhone, BlackBerry, Android etc. to be accepted for PA-DSS validation which means that such products won't be able to achieve PCI PA-DSS compliance and therefore used as part of merchant’s PCI DSS compliant environment. This limitation won’t affect applications developed for special devices intended especially for payment processing. PCI SSC does not specify such devices so it is unclear who and how is supposed to classify the hardware and determine whether it is eligible for validation. The Council also promised to further clarify the situation with mobile payments and “produce additional guidance by the end of the year”.
It should be still possible to avoid an issue with the validation of mobile payment application if software installed on mobile device does not store or process sensitive card data because in this case the application would not fall into the definition of payment application as described in PA-DSS, and therefore is not required not pass the validation at all.

Using your mobile phone as a token generator for two-factor authentication is becoming de-facto standard and common solution used by major companies operating online for extra protection of user accounts from unauthorized access. Such services are provided for free which is not the case with hardware token products like RSA SecurID and VeriSign VIP. In fact, software solutions also use device, which is your mobile phone, but since this is your phone and they do not have to produce and supply to you any special hardware - such services require no additional costs and therefore can be provided for free.  
What is two-factor (or two-step) authentication? It combines two factors (from maximum three available factor types according to the security theory): something you know (such as  username/password or pin code) with something you have (magnetic or smart card, token key, or mobile phone). Third possible factor is something you  are which is biometrics.
There are three major methods of two-factor implementation used by online service providers: hardware tokens, SMS, and smart phone application (software) tokens. Hardware tokens are usually offered for money and therefore less common than SMS or software tokens. Also, major hardware token solution RSA SecurID has been recently compromised which even increased the motivation for using software solutions.
Many online service providers implement two-factor combined from username/password (first factor) and mobile phone (second factor) which provides relatively high security level comparing to traditional single factor authentication (username/password only).
Some giants such as Facebook and Bank of America offer only SMS solutions for mobile phones. One-time token (6 digit number) is generated by the server and sent to user’s mobile phone as SMS text. Other companies such as PayPal provides SMS service as well as more convenient smart phone app (also used by eBay). In latter case VeriSign VIP software installed on iPhone, Android or other smart phone device generates new one-time token code (the same 6 digits) every minute. The advantage of software solutions is that they do not require any communication between mobile device and server which completely eliminates data transfer or text message fees.
Google offers even more options - application tokens, SMS and also voice messages.
Regardless the particular implementation, any form of two-factor authentication provides higher level of security and makes your account significantly less desirable target for hackers comparing to regular accounts protected by just user/password.

Read my article about secure .NET client/server communication created in July 2010 and finally posted today:

Read my article about secure .NET application deployment created in August 2010 and finally posted today: