September 17th, 2014 by Elma Jane
Host Card Emulation (HCE) offers virtual payment card issuers the promise of removing dependencies on secure element issuers such as mobile network operators (MNOs). HCE allows issuers to run the payment application in the operating system (OS) environment of the smart phone, so the issuing bank does not depend on a secure element issuer. This means lower barriers to entry and potentially a boost to the NFC ecosystem in general. The issuer will have to deal with the absence of a hardware secure element, since the OS environment itself cannot offer equivalent security. The issuer must mitigate risk using software based techniques, to reduce the risk of an attack. Considering that the risk is based on probability of an attack times the impact of an attack, mitigation measures will generally be geared towards minimizing either one of those.
To reduce the probability of an attack, various software based methods are available. The most obvious one in this category is to move part of the hardware secure element’s functionality from the device to the cloud (thus creating a cloud based secure element). This effectively means that valuable assets are not stored in the easily accessible device, but in the cloud. Secondly, user and hardware verification methods can be implemented. The mobile application itself can be secured with software based technologies.
Should an attack occur, several approaches exist for mitigating the Impact of such an attack. On an application level, it is straightforward to impose transaction constraints (allowing low value and/or a limited number of transactions per timeframe, geographical limitations). But the most characteristic risk mitigation method associated with HCE is to devaluate the assets that are contained by the mobile app, that is to tokenize such assets. Tokenization is based on replacing valuable assets with something that has no value to an attacker, and for which the relation to the valuable asset is established only in the cloud. Since the token itself has no value to the attacker it may be stored in the mobile app. The principle of tokenization is leveraged in the cloud based payments specifications which are (or will soon be) issued by the different card schemes such as Visa and MasterCard.
HCE gives the issuer complete autonomy in defining and implementing the payment application and required risk mitigations (of course within the boundaries set by the schemes). However, the hardware based security approach allowed for a strict separation between the issuance of the mobile payment application on one hand and the transactions performed with that application on the other hand. For the technology and operations related to the issuance, a bank had the option of outsourcing it to a third party (a Trusted Service Manager). From the payment transaction processing perspective, there would be negligible impact and it would practically be business as usual for the bank.
This is quite different for HCE-based approaches. As a consequence of tokenization, the issuance and transaction domains become entangled. The platform involved in generating the tokens, which constitute payment credentials and are therefore related to the issuance domain, is also involved in the transaction authorization.
HCE is offering autonomy to the banks because it brings independence of secure element issuers. But this comes at a cost, namely the full insourcing of all related technologies and systems. Outsourcing becomes less of an option, largely due to the entanglement of the issuance and transaction validation processes, as a result of tokenization.
Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa, Near Field Communication, Visa MasterCard American Express Tagged with: (MNOs), (OS), assets, bank, card, card issuers, cloud, cloud based payments, cloud based secure element, cloud-based, hardware secure element, Host Card Emulation (HCE), issuing bank, MasterCard, mobile, mobile app, mobile application, mobile network operators, mobile payment, mobile payment application, nfc, operating system, payment application, payment transaction, payments, platform, risk, secure element, smart phone, software, software based technologies, token, tokenization, transaction, virtual payment, visa
May 8th, 2014 by Elma Jane
The complexity derives from PCI’s Data Security Standards (DSS), which include up to 13 requirements that specify the framework for a secure payment environment for companies that process, store or transmit credit card transactions.
Make PCI DSS Assessment Easier
Training and educating employees. Technical employees should obtain any certifications or training classes necessary so that they can operate and monitor the security control set in place. Non-technical employees must be trained on general security awareness practices such as password protection, spotting phishing attacks and recognizing social engineering. All the security controls and policies in the world will provide no protection if employees do not know how to operate the tools in a secure manner. Likewise, the strongest 42-character password with special characters, numbers, mixed case, etc. is utterly broken if an employee writes it on a sticky note attached to their monitor.
For an organization to effectively manage its own risk, it must complete a detailed risk analysis on its own environment. Risk analysis goal is to determine the threats and vulnerabilities to services performed and assets for the organization. As part of a risk assessment, organization should define critical assets including hardware, software, and sensitive information and then determine risk levels for those components. This in turn allows the organization to determine priorities for reducing risk. It is important to note that risks should be prioritized for systems that will be in-scope for PCI DSS and then other company systems and networks.
Once the risk assessment has been completed the organization should have a much clearer view of its security threats and risks and can begin determining the security posture of the organization. Policies and procedures form the foundation of any security program and comprise a large percentage of the PCI DSS requirements. Business leaders and department heads should be armed with the PCI DSS requirements and the results of the risk analysis to establish detailed security policies and procedures that address the requirements but are tailored to business processes and security controls within the organization.
Building upon the foundation of security policies, the committee of business leaders and department heads should now review the PCI DSS requirements in detail and discuss any potential compliance gaps and establish a remediation plan for closing those gaps. This is where it is important to have the full support of business leaders who can authorize necessary funds and manpower to implement any remediation activities.
This is also the time to schedule the required annual penetration testing. These are typically performed by third parties, but is not required to be performed by third parties, and can take some time to schedule, perform, and remediate (if necessary). The results of a PCI DSS assessment will be delayed until the penetration test is completed so now is the time to schedule the test.
At this point the organization is ready for a full-scale PCI DSS assessment and can now enter a maintenance mode where periodic internal audits occur and regular committee meetings are held to perform risk assessments and update policies, procedures, and security controls as necessary to respond to an ever changing threat landscape. PCI DSS must become integrated into the everyday operation of the organization so that the organization remains secure and to ease the burden of the annual assessments.
Payment Card Industry (PCI) compliance assessment is a major task for any size organization, but you can make it easier.
Posted in Best Practices for Merchants, Credit Card Security, Payment Card Industry PCI Security Tagged with: assets, card, card transactions, compliance, compliance assessment, credit card transactions, credit-card, data security standards, DSS, networks, password protection, payment, Payment Card Industry, PCI, Phishing, process, risk, risk analysis, risk assessment, secure payment, Security, security control, security policy, transactions, transmit
