PCI
January 12th, 2016 by Elma Jane

Can we securely store card data for recurring billing?

PCI DSS discourages businesses from storing credit card data, Merchants feel the practice is necessary in order to facilitate recurring payments.

The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle branded credit cards from the major card schemes including Visa, MasterCard, American Express, Discover, and JCB.

In order for the electronic storage of cardholder data to be PCI Compliant, appropriate encryption must be applied to the primary account number (PAN). In this situation, the numbers in the electronic file should be encrypted.

All PCI controls would apply to the environment in which the cardholder data is transmitted and stored. Tokenization can be implemented for recurring and/or delayed transactions. Travel Merchants and or Storage Facility could use this feature to help reduce the need for electronically stored cardholder data while still maintaining current business processes.

The best thing you can do for your business is to not store any cardholder data or personally identifiable information.

Tomorrow let’s tackle Encryption and Tokenization a strong combination to protect card data while reducing the cost of compliance!

 

Posted in Best Practices for Merchants, Credit card Processing, Credit Card Security, Payment Card Industry PCI Security, Travel Agency Agents, Visa MasterCard American Express Tagged with: , , , , , , , ,

May 19th, 2015 by Elma Jane

We’re now nearly midway through 2015, and payment security still remains a topic that stirs up great concern and confusion. While there is seemingly unanimous agreement on the need for heightened security, there’s uncertainty about those who are tasked with actually implementing it. Let’s dig deeper into EMV, P2PE and tokenization. How each will play a part in the next generation of securing payments, and how without properly working together they might just fall short.

 

 

Europay, MasterCard, and Visa (EMV) – A powerful guard against credit card skimming. EMV also uses cryptography to create dynamic data for every transaction and relies on an integrated chip embedded into the card.

Downside: For Independent Software Vendor (ISVs), the biggest downside of EMV is the complexity of creating an EMV solution. ISVs interested in certifying PINpads with a few processors face up to 22 months of costly work, and because there are a large number of pending certifications, processors will be backed up over the next few years.

It’s not impossible for an ISV to build EMV solutions in-house, but it’s difficult and unnecessary when there are plug-and-play EMV solutions available. These solutions include pre-packaged and pre-certified APIs that remove most of the need for research, the complexity and the burden of time and cost.

Point to Point Encryption (P2PE) – Secures devices, apps and processes using encrypted data with cryptographic keys only known to the payment company or gateway from the earliest point of the transaction, from tech-savvy criminals, jumping at their chance to intercept POS systems and scrape the memory from Windows machines.

How does a key get into card reader? Through an algorithm called derived unique key per transaction (DUKPT), or “duck putt.” DUKPT generates a base key that’s shared with device manufacturers securely, where output cardholder data is rendered differently each time a card is swiped, making it impossible to reverse engineer the card data. P2PE not only benefits the cardholders, but also the ISVs and merchants. PA-DSS certification was designed to address the problems created with cardholder data which is not encrypted.

Downside: P2PE isn’t cheap if an organization wants to do it in-house. The secure cryptographic device needed to manage the keys, Hardware Security Module (HSM), can cost $30-40,000 but when it’s built out, that total cost can jump to $100,000.

TOKENIZATION – The best way to protect cardholder data when it’s stored is using tokenization, a process which the PCI Security Standards Council describes as one where the primary account number is replaced with a surrogate value a token. For merchants dealing with recurring billing, future payments, loyalty programs and more, tokenization is critical.

Downside: Tokenization doesn’t prevent malware that’s remotely installed on POS devices. It’s possible, as seen with recent retail card breaches, for data to be stolen before it is tokenized. That’s why it’s essential to group tokenization together with P2PE and EMV to offer optimal security.

 

Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa, Payment Card Industry PCI Security, Visa MasterCard American Express Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

May 8th, 2015 by Admin

 

 

 

 

 

 

 

 

 

All merchants that accepts, transmit or stores cardholder data are required to be PCI (Payment Card Industry) Compliant. Most believe that because they do not charge the credit cards themselves, they are exempt. Why all agencies are required to be complaint even when they don’t charge credit cards themselves, and some steps to ensure your agency is PCI compliant.

What is PCI compliance?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that all companies that process, store or transmit credit card information maintain a secure environment. PCI applies to all organizations or merchants, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data. Travel agents accepting, storing and transmitting credit card information to suppliers, are required to be compliant too. Suppliers reinforce this through their travel agent guidelines/contracts. Travel Agency must adhere to the applicable credit card company’s procedures for credit card transactions.

Consequences of Not Being PCI Compliant

If an agency is not PCI compliant, the agency can lose the ability to process credit card payments with that supplier. Not being able to pay with client credit cards can be a serious roadblock for agencies, and an inconvenience for clients.

If you have a merchant account and are found to be out of compliance, you can be fined.

How to be PCI Compliant

Don’t store the CCV security code from the client’s credit card. The client does not have the authority to grant you permission to store their CCV code. The credit card company explicitly forbid storage of the CCV code.

Make sure you securely store any client information, including their credit card number and expiration date. If you use a CRM, ensure that you have a strong password. If your CRM database is stored on your computer hard drive, encrypt it (there is a great encryption software that is free of charge). If you have an IT resource, talk to them about installing a firewall on your network, installing anti-virus and anti-malware protection, and any other steps that you can take to secure your client data even further.

If you keep paper copies of client information, keep it in a locked filing cabinet or desk drawer. When you no longer need their credit card information, cross shred it.

Home based businesses are arguably the most vulnerable simply because they are usually not well protected, according to the PCI Compliance Guide. Having strong passwords, encryption, a firewall, anti-virus and anti-malware protection are all inexpensive steps that you can take to protect your business and your clients’ sensitive data.

If you receive a courtesy call reminding you about PCI Compliance, don’t ignore it.

 

 

Posted in Best Practices for Merchants, Credit card Processing, Credit Card Security, Payment Card Industry PCI Security Tagged with: , , , , , , , , , , , , , , , , , , , , , , ,

April 21st, 2015 by Elma Jane

An advanced strain of malware called “Punkey,” is capable of attacking Windows point of sale terminals, stealing cardholder data and upgrading itself while hiding in plain sight.

Researchers from Security vendor Trustwave discovered the new strain. The investigation found compromised payment card information and more than 75 infected, and active, Internet Protocol addresses for Windows POS terminals.

 

 

Punkey poses a unique threat to payment networks, particularly because it also can download updates for itself.

If the malware author has a new feature it wants to add or updates to get rid of bugs, it actually pushes the malware down from the command and control server, revealed by Trustwave’s SpiderLabs research center. Punkey operates like a typical Botnet.

The malware hides inside of the Explorer process, which exists on every Windows device and manages the opening of individual program windows. Punkey scans other processes on the terminal to find cardholder data, which it sends to the control server.

The malware performs key logging, capturing 200 keystrokes at a time. It sends the information back to its server to store passwords and other private information.

A year ago, security vendors warned retailers against using Windows XP at the point of sale, since Microsoft stopped supporting Windows XP security patches. However, even Punkey is not attacking Windows due to any vulnerability in the systems, so even merchants with newer versions of Windows are at risk.

Punkey just runs like any Windows binary would. Even if the system is upgraded or a new system is put in place, criminals are still getting malware on the POS in other ways.

Many retailers use remote desktop support software, which fraudsters take advantage of, they steal a password and install malware like a technician would install any software.

While Punkey represents a more sophisticated POS malware than Trustwave has seen previously, merchants can still protect themselves through attention to basic security best practices.

Merchants should update antivirus and firewall protections, monitor the remote access software, establish two-factor authentication and check network activity daily for anything out of the ordinary. Unfortunately, many organizations have neither the expertise nor the manpower to perform these tasks.

 

Posted in Best Practices for Merchants, Credit card Processing, Credit Card Reader Terminal, Credit Card Security, Mobile Point of Sale, Payment Card Industry PCI Security, Point of Sale Tagged with: , , , , , , , , , , ,

October 8th, 2014 by Elma Jane

When the PCI Security Standards Council (PCI SSC) launched PCI DSS v3.0 in January 2014, businesses were given one year to implement the updated global standard. Now that the deadline is fast approaching, interest is picking up in what v3.0 entails. On Jan. 1, 2015, version 3.0 of the Payment Card Industry (PCI) Data Security Standard (DSS) will reach year one of its three-year lifecycle.

Trustwave, a global data security firm, is on the frontlines of helping secure the networks of merchants and other businesses on the electronic payments value chain against data breaches. As an approved scanning vendor, Trustwave is used by businesses to achieve and validate PCI DSS compliance.

PCI DSS v3.0 is business as usual for the most part, except for a few changes from v2.0 that considers impactful for large swaths of merchants. The top three changes involve e-commerce businesses that redirect consumers to third-party payment providers. The expansion of penetration testing requirements and the data security responsibilities of third-party service providers.

Penetration testing

Penetration testing is the way in which merchants can assess the security of their networks by pretending to be hackers and probing networks for weaknesses. V3.0 of the PCI DSS mandates that merchants follow a formal methodology in conducting penetration tests, and that the methodology goes well beyond what merchants can accomplish using off-the-shelf penetration testing software solutions.

Merchants that are self assessing and using such software are going to be surprised by the rigorous new methodology they are now expected to follow.

Additionally, penetration testing requirements in v3.0 raises the compliance bar for small merchants who self assess. Those merchants could lower the scope of their compliance responsibilities by segmenting their networks, which essentially walls off data-sensitive areas of networks from the larger network. In this way merchants could reduce their compliance burdens and not have to undergo penetration testing.

Not so in v3.0. If you do something to try to reduce the scope of the PCI DSS to your systems, you now need to perform a penetration test to prove that those boundaries are in fact rigid.

Redirecting merchants

The new redirect mandate as affecting some, but not all, e-commerce merchants that redirect customers, typically when they are ready to pay for online purchases to a third party to collect payment details. If you are a customer and you are going to a website and you add something to your shopping cart, when it comes time to enter in your credit card, this redirect says I’m going to send you off to this third party.

The redirect can come in several forms. It can be a direct link from the e-commerce merchant’s website to another website, such as in a PayPal Inc. scenario, or it can be done more silently.

An example of the silent method is the use of an iframe, HTML code used to display one website within another website. Real Estate on the merchant’s website is used by the third-party in such a way that consumers don’t even know that the payment details they input are being collected and processed, not by the e-commerce site, but by the third party.

Another redirect strategy is accomplished via pop-up windows for the collection of payments in such environments as online or mobile games. In-game pop-up windows are typically used to get gamers to pay a little money to purchase an enhancement to their gaming avatars or advance to the next level of game activity.

For merchants that employ these types of redirect strategies, PCI DSS v3.0 makes compliance much more complicated. In v2.0, such merchants that opted to take Self Assessment Questionnaires (SAQs), in lieu of undergoing on-site data security assessments, had to fill out the shortest of the eight SAQs. But in v3.0, such redirect merchants have to take the second longest SAQ, which entails over 100 security controls.

The PCI SSC made this change because of the steady uptick in the number and severity of e-commerce breaches, with hackers zeroing in on exploiting weaknesses in redirect strategies to steal cardholder data. Also, redirecting merchants may be putting themselves into greater data breach jeopardy when they believe that third-party payment providers on the receiving end of redirects are reducing merchants’ compliance responsibilities, when that may not, in fact, be the case.

Service providers

Service provider is any entity that stores, processes or transmits payment card data. Examples include gateways, web hosting companies, back-up facilities and call centers. The update to the standard directs service providers to clearly articulate in writing which PCI requirements they are addressing and what areas of the PCI DSS is the responsibility of merchants.

A web hosting company may tell a merchant that the hosting company is PCI compliant. The merchant thought, they have nothing left to do. The reality is there is still always something a merchant needs to do, they just didn’t always recognize what that was.

In v3.0, service providers, specifically value-added resellers (VARs), also need to assign unique passwords, as well as employ two-factor authentication, to each of their merchants in order to remotely access the networks of those merchants. VARs often employ weak passwords or use one password to access multiple networks, which makes it easier for fraudsters to breach multiple systems.

The PCI SSC is trying to at least make it more difficult for the bad guys to break into one site and then move to the hub, so to speak, and then go to all the other different spokes with the same attack.

Overall, v3.0 is more granular by more accurately matching appropriate security controls to specific types of merchants, even though the approach may add complexity to merchants’ compliance obligations. On the whole a lot of these changes are very positive.

 

Posted in Best Practices for Merchants, Credit Card Security, Payment Card Industry PCI Security Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

April 11th, 2014 by Elma Jane

PCI DSS 3.0 standard, which took effect January 1st, introduces changes that extend across all 12 requirements, aimed to improve security of payment card data and reducing fraud. There will be some shakeups for many organizations when it comes to their day-to-day culture and operations. Transitioning to meet the new requirements will help e-business build a stronger, safer, lower-risk environment for their customers.

While the growing number of digital payment avenues offers convenience to customers, it also offers a larger attack surface for criminals.

As cloud technologies and e-commerce environments continue to grow, creating multiple points of access to cardholder data and online retailers will only become more appealing targets for hackers. Cybercriminals are cunning and determined. They understand payment card infrastructures as well as the engineers who designed them.

A scary proposition and it’s exactly why the payment card industry is so determined to help keep e-commerce organizations protected. Meeting the new standard, businesses will be better armed to fight evolving threats. Changes will also drive more consistency among assessors, help business reduce risk of compromise and create more transparent provider-customer relationships.

Transitioning to PCI DSS 3.0 will involve some work, but doing that work on the front end is going to save much work down the line. Adopting the new standard ultimately will drive your e-commerce business into a secure and efficient era.

Cultural Changes – One of the main themes of 3.0 is shifting from an annual compliance approach to embedding security in daily processes. Threats don’t change just once a year. They’re constantly evolving and that means e-commerce organizations must adopt a culture of vigilance. Only through a proactive business-as-usual approach to security can you achieve true DSS compliance. Realistically, this could mean the need to provide more education and build awareness with staff, partners and providers, so that everyone understands why and how new processes are in place.  

Operational Changes – The 3.0 standard addresses common vulnerabilities that probably will ring a bell with many of you. These include weak passwords and authentication procedures, as well as insufficient malware detection systems and vulnerability assessments, just to name a few. Depending on your current security controls program, this could mean you’ll need to step up in these areas by strengthening credential requirements, resolving self-detection challenges, testing and documenting your cardholder data environment and making other corrections.

Overview Changes – How much work lands on your plate will depend on your current security program. Examining your current security strategies and program is a good idea. Below are the areas requiring your attention, which this series will explore in more detail in future installments.

Service Provider Changes –  Some organizations made unsafe assumptions in the past when it comes to third-party providers. Some have paid the price, from failed audits to breaches. One reason that the new standard is designed to eliminate any confusion over compliance responsibilities. Responsibilities, specifically for management, operations, security and reporting all will need to be spelled out in detailed contracts. In addition to improved communication, an intensified focus on transparency means that you should have a clear view of your provider’s infrastructure, data storage and security controls, along with subcontractors that can impact your environment. So if your organization isn’t exactly clear on which PCI DSS requirements you manage and which ones your providers handle, prepare to get all of that hammered out.

The Compliance Rewards – The path to preparing for the 3.0 deadline in January 2015 sounds like it’s a lot of work. So to get started request your QSA’s opinion on how the changes will impact your organization, by doing the gap assessment and you’ll be able to address any shortcomings.    

Meeting the new 3.0 requirements isn’t just about passing audits. In fast paced payment IT landscape, staying smart and protected is part of our commitment to our customers. Beefing up security game not only reduce audit headaches, but also enjoy stronger brand reputation as a safe and reliable e-commerce business.

Posted in Best Practices for Merchants, Credit card Processing, Credit Card Security, e-commerce & m-commerce, Electronic Payments, Financial Services, Payment Card Industry PCI Security, Small Business Improvement, Visa MasterCard American Express Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

February 13th, 2014 by Elma Jane

Core Elements of PCI’s Data Security Standard

This organization provides an international platform for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection. It is impossible to be involved in the credit card processing industry and not be aware of the PCI Security Standards Council.

As such it is important to be aware of the core elements of the PCI’s Data Security Standard (DSS).

The following are the current fundamental principles and requirements:

Build and Maintain a Secure Network

Requirement a. Install and maintain a firewall configuration to protect cardholder data
Requirement b. Do not use vendor-supplied defaults for system passwords and other security parameters

Implement Strong Access Control Measures

Requirement c. Restrict access to cardholder data by business need-to-know
Requirement d. Assign a unique ID to each person with computer access
Requirement e. Restrict physical access to cardholder data

Maintain a Vulnerability Management Program

Requirement f. Use and regularly update anti-virus software
Requirement g. Develop and maintain secure systems and applications

Maintain an Information Security Policy

Requirement h. Maintain a policy that addresses information security

Protect Cardholder Data

Requirement i. Protect stored cardholder data
Requirement j. Encrypt transmission of cardholder data across open, public networks

Regularly Monitor and Test Networks

Requirement k. Track and monitor all access to network resources and cardholder data
Requirement l. Regularly test security systems and processes

 

Posted in Best Practices for Merchants, Credit card Processing, Credit Card Security, Payment Card Industry PCI Security Tagged with: , , , , , , , , , ,