In the last 8–10 years the expertise of hackers has grown immensely. It is imperative that your company and your merchant portfolio are PCI DSS compliant at all times to protect against these pernicious criminals.
Although there is not a single “silver bullet” that will solve all of your security requirements, good security requires focusing on IT security, and good IT security is about layers. Merchants can only achieve security in their system utilizing a layered approach.
I often find that doing a few, simple things could have prevented an intrusion. From an experts view, the merchant needs to focus on three areas:
1. Keep attackers out of your system in the first place.
2. If attackers get in, make sure there is nothing in the system of value.
3. If attackers do get into a merchant system and discover something they want, make it difficult for them to get the information out of that system.
1. Keep attackers out of your system in the first place.
In many cases, all it takes is a simple, properly configured firewall to prevent a hacker from entering your system. Nearly 50% of all Level 4 merchants that we investigate do not have a properly configured firewall in place. Processing credit cards without a firewall is a virtual ticking time bomb.
Remote access is another potential “open door.” The problem that I often see is that remote access is not set up securely. Attackers often hack into systems via remote access because of simple vulnerabilities such as the use of non-complex, or default passwords. A password should not be found in a dictionary, of any language. It should contain upper and lower case characters, numbers and special characters. It should not be anything that anyone would recognize.
Remote access should also require two-factor authentication, or two separate steps to authenticate the user. Two-factor authentication is a much more difficult roadblock for the hacker to overcome.
Another security essential is to segregate the merchant’s day-to-day business and internet traffic from the payment application (PA). The best method to accomplish this is to operate separate servers – one for routine business and one for your PA that are segmented from each other by a firewall.
The merchant needs to consider their wireless network. I must admit I am not a fan of payment applications being run on wireless networks. This was the Achilles heel of TJ Maxx, a US retailer that is reported to have lost 45.7 million credit cards to hackers. If there is a business need that requires the merchant to process credit cards in a wireless environment, ensure that the wireless network is protected by strong encryption. Take the time to research whether there is a known method to hack that particular wireless encryption. If there is, I recommend choosing a stronger encryption platform.
2. If attackers get in, make sure there is nothing in the system of value.
It is essential the merchant has a properly configured PA that is compliant with current PA DSS (Payment Application Data Security Standards). A PA DSS compliant payment application does not store unencrypted credit card data on the system.
SecurityMetrics’ Forensics department recently completed a forensics investigation for a small merchant that had the same PA in place since 2004. The merchant was not aware that the PA was storing transaction logs. When our forensics team examined the system we saw every transaction (along with the unencrypted credit card data) for the merchant since early 2004. The sad part is, so did the attacker.
3. If attackers do get into a merchant system and discover something they want, make it difficult for them to get the information out of that system.
There are several common methods hackers use to export data out of systems. One method is by simply emailing the captured data back to themselves. The attacker will typically automate his attack to email captured data back to himself at set intervals. Another way attackers get the data out is via File Transfer Protocol (FTP). They will simply FTP the data directly out of the system.
There are a couple of steps merchants should take to prevent both of these methods.
First, disable FTP. Next, configure the firewall so that data leaving the PA can only be sent to known, trusted sources, such as your payment processor, and “black list” all other IP addresses. We frequently see firewalls that are configured to filter only the inbound traffic. Filtering outbound traffic can greatly limit an attacker’s ability to get data out of your system.
The security recommendations outlined in this article are not comprehensive and their implementation is dependent upon the merchant’s particular needs. Although this specific article is targeted to address small (Level 4) merchants, the concepts are universal and can also be applied to larger environments.
Utilizing a layered approach to your IT security and staying PCI DSS compliant are essential keys in staying ahead of hackers. Payment card security can be a complex issue, but with basic understanding and the right help, merchants can achieve a highly secure state and avoid the cost of a compromise.
Posted by David Ellis: Director of Forensics Examinations, CISSP
Although there is not a single “silver bullet” that will solve all of your security requirements, good security requires focusing on IT security, and good IT security is about layers. Merchants can only achieve security in their system utilizing a layered approach.
I often find that doing a few, simple things could have prevented an intrusion. From an experts view, the merchant needs to focus on three areas:
1. Keep attackers out of your system in the first place.
2. If attackers get in, make sure there is nothing in the system of value.
3. If attackers do get into a merchant system and discover something they want, make it difficult for them to get the information out of that system.
1. Keep attackers out of your system in the first place.
In many cases, all it takes is a simple, properly configured firewall to prevent a hacker from entering your system. Nearly 50% of all Level 4 merchants that we investigate do not have a properly configured firewall in place. Processing credit cards without a firewall is a virtual ticking time bomb.
Remote access is another potential “open door.” The problem that I often see is that remote access is not set up securely. Attackers often hack into systems via remote access because of simple vulnerabilities such as the use of non-complex, or default passwords. A password should not be found in a dictionary, of any language. It should contain upper and lower case characters, numbers and special characters. It should not be anything that anyone would recognize.
Remote access should also require two-factor authentication, or two separate steps to authenticate the user. Two-factor authentication is a much more difficult roadblock for the hacker to overcome.
Another security essential is to segregate the merchant’s day-to-day business and internet traffic from the payment application (PA). The best method to accomplish this is to operate separate servers – one for routine business and one for your PA that are segmented from each other by a firewall.
The merchant needs to consider their wireless network. I must admit I am not a fan of payment applications being run on wireless networks. This was the Achilles heel of TJ Maxx, a US retailer that is reported to have lost 45.7 million credit cards to hackers. If there is a business need that requires the merchant to process credit cards in a wireless environment, ensure that the wireless network is protected by strong encryption. Take the time to research whether there is a known method to hack that particular wireless encryption. If there is, I recommend choosing a stronger encryption platform.
2. If attackers get in, make sure there is nothing in the system of value.
It is essential the merchant has a properly configured PA that is compliant with current PA DSS (Payment Application Data Security Standards). A PA DSS compliant payment application does not store unencrypted credit card data on the system.
SecurityMetrics’ Forensics department recently completed a forensics investigation for a small merchant that had the same PA in place since 2004. The merchant was not aware that the PA was storing transaction logs. When our forensics team examined the system we saw every transaction (along with the unencrypted credit card data) for the merchant since early 2004. The sad part is, so did the attacker.
3. If attackers do get into a merchant system and discover something they want, make it difficult for them to get the information out of that system.
There are several common methods hackers use to export data out of systems. One method is by simply emailing the captured data back to themselves. The attacker will typically automate his attack to email captured data back to himself at set intervals. Another way attackers get the data out is via File Transfer Protocol (FTP). They will simply FTP the data directly out of the system.
There are a couple of steps merchants should take to prevent both of these methods.
First, disable FTP. Next, configure the firewall so that data leaving the PA can only be sent to known, trusted sources, such as your payment processor, and “black list” all other IP addresses. We frequently see firewalls that are configured to filter only the inbound traffic. Filtering outbound traffic can greatly limit an attacker’s ability to get data out of your system.
The security recommendations outlined in this article are not comprehensive and their implementation is dependent upon the merchant’s particular needs. Although this specific article is targeted to address small (Level 4) merchants, the concepts are universal and can also be applied to larger environments.
Utilizing a layered approach to your IT security and staying PCI DSS compliant are essential keys in staying ahead of hackers. Payment card security can be a complex issue, but with basic understanding and the right help, merchants can achieve a highly secure state and avoid the cost of a compromise.
Posted by David Ellis: Director of Forensics Examinations, CISSP