Why PCI DSS Compliance Is Important For Smartcards?
As more and more people are conducting their everyday financial transaction needs through the use of smartcards, that is the reality on the ground. People use less cash, and the growing demand for the use of debit/credit cards is globally speaking the release of EMV cards to replace magnetic stripe cards are not yet fully implemented. Hence the PCI DSS Goals and Requirements are established in order to guide the financial sector.
The six goals with their corresponding requirements are enumerated below:
1. Build and maintain secure networks and systems:
Install and maintain a firewall to protect cardholder data
This is the responsibility of system administrators and their team of IT staff. The smartcard itself is just a frontend, the “magic” of using a piece of plastic card in on its backend, the servers that supports the electronic transactions. Both the merchant and the bank are connected by this network that is expected to run 24/7, as ecommerce never stops as office hours stop.
Do not use vendor-supplied defaults for system passwords and other security parameters
Trouble comes with the “default”, there is a term in the IT support industry called the “tyranny of the default”, where the end-user are totally dependent on the default values. Default values for passwords are documented in the web, never use them for a production system.
2. Protect cardholder data
Protect stored cardholder data
Physical security is still one of the strongest security to implement. But immediately succeeding it is the stored data itself that gets read and written through machines like ATMs and POS terminals. It is the full responsibility of banks and merchants that their terminals fully comply with the current security standards.
Encrypt when transmitting cardholder data over an open public network
This is a common practice across the industry, no one will trust a merchant with non-encrypted POS, and no one will ever transact with a bank that has no reasonable implementation of encryption standards practice all around the world for securing their customer’s data.
3. Maintenance of vulnerability management program
Protect all systems as malware and update anti-virus software regularly
Malware infection vulnerability is the very reason why POS and ATM machines are usually running a variant of the Unix and Linux operating systems. This is due to the number of malware available in the Windows platform, it is not recommended for use in merchandising and banking purposes.
Develop and maintain highly secure systems and applications
Many banks maintain their old but still dependable Unix systems, some banks even uses the decades-old mainframe systems for the same reason, security.
4. Introducing powerful access control methods
Restrict access to cardholder data to the extent necessary for business
Also known as user account control, only those bank employees and merchant staff tasks with handling data of customers should have access to customer information.
Identify and authenticate access to system components
Aside from time-tested vaults, banks using their Unix/Linux systems have elaborate components that work together in a secure fashion.
Restrict physical access to cardholder data
Same as number 7, however, securing data on the card is itself is the full responsibility of the owner. Misuse of the card does not make the bank responsible for fraudulent transactions.
5. Regular monitoring and testing of the network
- Track and monitor all access to network resources and cardholder data
- Test security systems and processes regularly
6. Development of information security policy
- Develop a policy to support information security for all personnel
Julia Sowells960 Posts
Julia Sowells has been a technology and security professional. For a decade of experience in technology, she has worked on dozens of large-scale enterprise security projects, and even writing technical articles and has worked as a technical editor for Rural Press Magazine. She now lives and works in New York, where she maintains her own consulting firm with her role as security consultant while continuing to write for Hacker Combat in her limited spare time.