Another local company recently sent out notices to customers stating they “may have” experienced a breach of their system.  We all know how this story goes – “may have” turns into “a small number of customers were affected” turns into “all customers should monitor their credit cards and credit reports for suspicious activity.”  When will this stop?  Only when merchants understand the responsibility they signed up for when agreeing to accept credit cards as a form of payment. The responsibility to protect private cardholder data falls fully on the merchant. In a case like this, the merchant will experience fines, loss of reputation/business, and possible loss of ability to accept credit cards as a form of payment altogether.

The first thing merchants must do to protect themselves is understand their environment when collecting a credit card. Before the Internet, processing a credit card by using a dedicated terminal was relatively safe. The configuration consisted of a terminal that included software and direct connection (POTS) to the payment processor.

But as the Internet, software and mobile have proliferated, dedicated hardware solutions have been replaced. Direct connections have given way to the cheap interconnectivity of the Internet, costly dedicated hardware has been replaced by software, and business line software solutions have automated payment acceptance. These innovations have provided great cost savings to merchants in equipment, communication, and automation, but come with a price many merchants haven’t realized.  That price is PCI compliance and protecting private cardholder data.

A common payment solution today most likely employs technology on each layer of the PCI Compliance Pyramid. Merchants need to be aware of this and ensure that each layer has the proper security to protect against hackers and secure private cardholder data.

THE PCI COMPLIANCE PYRAMID

This pyramid is a representation of the various layers a typical payment software solution may employ. Connecting the layers together are communication channels. All layers and communication channels must be protected to help ensure hackers cannot steal information along the path of a payment transaction or steal an entire database of cardholder data.

• Hardware – Most software applications run on some type of computing hardware device.  This could be a cell phone, IoT, credit card swiper, or keyboard connected to a computer.  Merchants need to ensure that the devices used to enter credit card information are not physically compromised. Examples include a hacked credit card reader that collects and transmits credit card information, malware, viruses, keyboard loggers, etc. If using a standard computer program such as a POS program or Accounting system, P2PE encrypted devices such as credit card readers and keyboards can be used to safeguard the cardholder’s information at the source of entry.  Information is encrypted at the hardware layer and protects it as it travels through the computing device and other levels. The benefit to merchants employing hardware-level encryption is reducing the PCI exposure level. The PCI Security Council has recently released the P2PE SAQ for these types of environments and it is minimal compared to more comprehensive PCI SAQs.
• Applications – Most on-premises software applications store information in local databases. Some may use local encryption to store sensitive data, but the data still resides on the merchant’s computers and networks making them a target for hackers. A better solution for sensitive cardholder data is to use a solution that directs that information to a secure outside source using technology such as an iFrame window.
• Data Storage – Removing sensitive data from the local environment should be priority number one. Today, solutions allow customers to continue to use their traditional business line systems locally, but keep the sensitive data offsite in a secure and encrypted data storage service. Tokenization and encryption services help protect businesses by removing all data from a single location.
• Gateways/Processors – Businesses need to stay up-to-date with the ways their payment gateway is connecting to the various processors. The PCI Security Council has mandated that all payment connectivity utilize a minimum-security protocol of TLS 1.2 by June 2018. Older security protocols such as SSL have proven to be vulnerable to hackers and should be updated as soon as possible.
• Communications – As cardholder information is collected on any level of the PCI Compliance Pyramid, the communication channel used to move it to the next layer should also be secure. This can be accomplished with encryption and tokenization.

Industry statistics from PCI authorized scanning vendors in 2016 found that 67% of company networks contained unsecure cardholder data. The top source of this private information was found within company ERP systems and was vulnerable to outside hackers. Other areas found to have unsecure cardholder data included error logs and CRM systems.

Companies employ many systems today that touch cardholder data to facilitate payment acceptance. Some examples include accounting systems, eCommerce sites, CRM, point-of-sale, field service, etc. To complicate matters more, many of these systems interconnect with other systems for the exchange and automation of data. So how does a company protect itself from the bad guys trying to steal this information and reduce their risk? The answer is understanding the challenge by reviewing the PCI Compliance Pyramid and identifying vulnerabilities within the company’s infrastructure. Once vulnerabilities are determined, solutions can be explored.

Solutions safeguarding cardholder data do not have to be complicated. For card present solutions, EMV can provide safety far beyond what was available for magnetic stripes. These solutions have been so effective; fraud has migrated to eCommerce and card-not-present (CNP) transactions.  So companies should seek similar types of solutions to protect CNP cardholder data. This can include simple offerings that encrypt data at the entry source, store it offsite using tokenization and transmit it in an encrypted format without affecting the business line system. These solutions are relatively new and work with existing CRM and accounting systems such as Microsoft Dynamics AX, GP, NAV and the business line systems that connect to them.  Examples of business line systems sharing data with a company accounting system may include bank treasury management, accounts receivable/payable automation, online customer portals and field sales/service. Protecting the payment data within all of these systems is greatly simplified with a unified PCI certified solution.

Chester Ritchie is the President of Nodus Technologies (http://www.nodus.com/blog).  Nodus is a certified Microsoft Gold Level Partner for payment software within the Microsoft Dynamics family of accounting systems.  Nodus products allow users of GP, SL, CRM and AX to accept electronic payments inside of the accounting system. Accounting entries related to payments are automated and cash flow is increased.[/vc_column_text][/vc_column][/vc_row]