Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Electronic Payments and Security with NCR Counterpoint

No description
by

Barry Moomaw

on 13 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Electronic Payments and Security with NCR Counterpoint

Electronic Payments and Security - NCR Counterpoint
EMV
E
uropay,
M
asterCard,
V
isa
Standard for electronic payment cards with a smart card processor embedded in the card
Cardholder data and payment applications stored on processor
PIN-based or Signature-based
Requires EMV Card Reading Hardware
Card remains in an EMV reader for the duration of a payment transaction
Tokenization
Token replacement, or tokenization, of stored data literally replaces a data element with a reference to that data element stored in a separate physical and/or logical location
In the case of NCR Counterpoint using NCR Secure Pay, tokenization is used in the Counterpoint database
Where credit card numbers have been encrypted for years, NCR Counterpoint, when used with NCR Secure Pay, will automatically use tokens rather than encrypted card numbers for transaction history and card on file purposes

Point-to-Point Encryption
Why we are talking
about EMV
In the wake of the Target breach, the NRF president and others have been calling on EMV as the technology to end credit card security problems
Benefits of EMV
Because of the smart card processor embedded in the payment card, and the hardware required to read the card, creation of fraudulent cards is much less likely
In PIN-based implementations, fraudulent use is less likely
About the same per-transaction speed as PIN Debit
Consumer retains possession of cards at all times
Limitations of EMV
Encryption or tokenization/secure storage
While EMV card creation and use may be less likely to reduce fraudulent creation and card use, it does not encrypt personal account information inherently, so it will be up to each POS provider and/or EMV device manufacturer to come up with standards for encryption and retention
NCR Counterpoint EMV Plan
NCR Secure Pay development of EMV support in progress
Expect to begin NCR Secure Pay to processor certifications in Q3
Ingenico iSC250 already supports EMV with Signature and PIN, from a manufacturer’s standpoint - will need device software update
Add NCR Counterpoint support for the Ingenico’s EMV capabilities, and certify processing with NCR Secure Pay – development will in Q4 2014.
Release in 2015

PCI Implications of EMV
Currently, there is no overlap between PCI and EMV
EMV will be a requirement of merchants and will help with liability in the event a fraudulent card is used



EMV - Related Dates
April 2013
- Mandate for processor support

October 2014
– NCR Counterpoint development will commence - release in 2015

October 2015
– Date by which merchants are “required” to accept EMV. Will be mandated by processors.

Other EMV Notes
EMV cards can be used online (ecommerce) like plain ol’ credit cards today, which is an example of why it not having encryption is relevant
Took 10 years in Canada to replace 60% of terminals
US market 10-20 times larger than Canada
EMV readers will almost exclusively peripherals on terminals, given PIN need
As it pertains to Electronic Payments, describes technology that encrypts at the electronic payment card input hardware, and decrypts at a credit switch/gateway or credit processor.
Primary P2PE Benefits
Because the input hardware is injected with encryption keys, the resulting encrypted data can only be decrypted at the credit switch or credit processor
Credit card data is encrypted throughout its lifecycle in a merchant’s cardholder data environment, increasing the security of a merchant’s POS system significantly
There is a PCI benefit as well, allowing POS, in some cases, to be deemed as having reduced scope for PCI assessment/attestation

P2PE Limitations
P2PE does not address counterfeit card creation or use
Does not address storage of encrypted card numbers
P2PE Status in Market
Starting to see availability
Most prevalent are relationships between payment terminal manufacturers and processors, where a processor injects a payment terminal with keys whose data can only be decrypted at the processor
These solutions lock merchants into a processor with the hardware
Software Requirements for P2PE
If integrated credit with the merchant’s POS, the POS has to be able to accept and allow proper “flow” of encrypted card numbers through the system
The POS can’t decrypt the numbers – that’s a security benefit, although has operational ramifications.
Hardware requirements for P2PE
Requires payment hardware to be injected with encryption keys sourced by the hosted credit solution
For NCR Counterpoint and NCR Secure Pay to do P2PE, then, it – keys have to be created and managed by NCR Secure Pay
Requires NCR Secure Pay injected hardware
NCR Counterpoint P2PE Plan
NCR Counterpoint software supports NCR Secure Pay P2PE credit data “flow through” in 8.4.6.6 and later
For LAN and Multi-Site implementations, NCR is ready to pilot with Magtek MagneSafe® USB MSR readers encrypted with NCR Secure Pay keys
For all implementation types, NCR is working with Ingenico to support the iSC250 with NCR Secure Pay encryption
iSC250 support will include the capability for card numbers manually entered into the device to be encrypted using P2PE keys
There will be a path for existing iSC250 units in the field to be injected with NCR Secure Pay P2PE keys, although it may require sending the units to an injection facility
NCR’s next generation POS terminal, the XR7, will support NCR Secure Pay encrypting MSR at its release. No plans for retrofit of P1530s

PCI Implications of P2PE
There exists the concept of a solution being a PCI Validated Point-to-Point Encryption solution
Our assessor, Coalfire, is a P2PE assessor, and once we have our HSM in place, we will pursue this validation
Benefits of this validation will be that merchants can more easily remove POS elements from their attestation associated with their Self-Assessment Questionnaire (SAQ)
In addition, we expect that some acquiring banks will allow the use of SAQ-C, rather than SAQ-D, for a merchant with a P2PE validated solution

P2PE Dates - NCR Counterpoint
In Pilot now with Magtek – first site expected any time
iSC250 P2PE Pilot expected by June 30th.
Expected Generally available NCR Secure Pay and NCR CP 8.4.6.11.
P2PE injection plan for pre-existing iSC250 field units expected by end of year

Other P2PE Info
If NCR Secure Pay injected payment input devices are purchased for a merchant, those devices need to be used with NCR Secure Pay as the payment gateway
Non-financial cards are not encrypted in an NCR Secure Pay P2PE encrypting MSR
For ecommerce transactions, P2PE is not a feasible possibility, as it is associated with physical encryption of card data when swiped or manually entered into a payment device

Primary Benefits of Tokenization
For sensitive data like credit card numbers, consolidates the actual encrypted sensitive data in single location outside of a merchant's cardholder data environment, making it much easier to protect
Reduces the likelihood of sensitive credit card data access from a Counterpoint implementation in the field

Tokenization Limitations
Tokenization does not encrypt credit card info in transit – that’s where P2PE comes in
No impact on fraudulent card creation, apart from making card numbers more difficult to harvest en masse
Software Requirements & NCR Counterpoint Plan
To take advantage of Tokenization of credit card data with NCR Counterpoint, need 8.4.6.9 or later and NCR Secure Pay - that's it.
For sites that make the switch from CPG to NCR Secure Pay, will need to “tokenize” existing Card on File data - Manual utility to be developed

Hardware Requirements for Tokenization
With NCR Counterpoint and NCR Secure Pay - None!
Use what you’ve got.

PCI Implications of Tokenization
Unfortunately, no specific implications that can be guaranteed
Acquiring banks typically are more forgiving on the SAQ Attestation, but this alone may not have acquiring banks allow a merchant to move from SAQ-D to SAQ-C

NCR Counterpoint Tokenization Dates
In Pilot now with NCR Secure Pay.
NCR Secure Pay General Release with NCR Counterpoint July.
Full transcript