7 Ways to Make a Card Management and Payment Processing System More Secure than PCI Requires

PCI is the major security compliance that all payment card systems have to follow and it safeguards them against attacks from hackers. Despite the compliance, hackers are sometimes able to break into these financial systems causing huge financial damage and privacy issues. Following are my recommendations to make your card management, payments, accounts receivable and lending systems secure beyond PCI DSS.

1. Block unauthorized or fraudulent users by IP address

PCI mandates blocking an account if there have been three unsuccessful login attempts with a wrong password. But it has no directives on the scenario in which an unauthorized user knows the password and is trying to guess the user ID. By blocking an IP address after a predefined number of failed login attempts (irrespective of wrong password or id), an unauthorized access by guessing user ID can be prevented. This practice also helps in case a hacker tries to send your web site a malicious URL. You can block the IP address after a couple of bad URL attempts to keep them from trying more.
Of course you should unblock the IP address after a reasonable time (like an hour) or when an identified authorized user who has been blocked calls for access.

2. Keep sensitive data in memory encrypted

PCI requires encryption of data that is saved in a database. You can be more secure by keeping ‘over the network’ and ‘in memory’ data encrypted. You should decrypt the data only when it is required in clear format. This will protect you against the memory scanning attacks which are on the rise currently.

3. Use multiple encryption keys

To minimize the extent of damage caused due to a compromised database you should use different keys to encrypt different sets of records in the same database. If you use only one key to encrypt all the data then your risk is unlimited as all cardholder information will be available to the hackers if hacked once. On the other hand, if say 1,000,000 cardholder records were encrypted using 1000 keys, the perpetrators will need to break through your encryption 1000 times, making it practically impossible to misuse all the information.

4. Support two-factor authentication

Users are humans and sometimes they get lazy with their passwords. It is bad practice, but not uncommon, to use one password for two different applications. If one application is PCI compliant and the other is not, then even the more secure PCI application is at risk if malcontent hackers are successful in finding the password used in the non-PCI compliant application. Using two-factor authentication (which requires a person to provide two evidences to prove that he is whom he claims to be) mitigates this risk significantly.

5. Encrypt all internal network traffic

You must have heard the story of the major card processor which was hacked using packet sniffers on its DB server. Personal information of hundreds of thousands of cardholders was compromised. Though not mandated by PCI, encrypting internal network traffic safeguards your system against such attacks.

6. Control logins by time of day

If a hacker does discover a user ID and password for a privileged user, many a times he will hold off using the account until they know that the user is not logged in to notice them.  If you know that a privileged user works from 9 to 5 only on weekdays, then limiting their login access from 8 AM to 6 PM on weekdays can block the hackers out.

7. Control logins by geographic location

For a variety of reasons, hackers will often attempt to break into your system from off shore.  There are many IP address to geographic location mappings available.  If you know that your developers, admin, tech support, call center or other users live in city X, then limiting the access to your system from IP addresses near that location will block-out large number of hackers.

Disclaimer: This is not an exhaustive list of security measures you should take. Please consult your system security experts to make sure that your software is not vulnerable to attacks.

Brian Beuning

Platform Architect

CoreCard Software, Inc.

www.corecard.com

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top