The Threat Landscape Has Changed

In an earlier post, I discussed how the PCI DSS changes based on changes in the threat landscape.  Attention, Robert Carr at Heartland Payment Systems and anyone else processing, storing or transmitting cardholder data, here is a change in the threat landscape that will radically affect the PCI security standards, most definitely the PA-DSS, but also the PCI DSS.

Verizon Business Services recently announced that they are seeing a rise in RAM scraping attacks.  RAM scraping is an attack that utilizes a program to go through the memory of a device looking for certain information.  RAM scraping has been around for quite a while, but only recently was this technique adapted for finding cardholder data.  With the push for end-to-end encryption, Verizon Business Services predicts that RAM scraping attacks will continue to rise.

Now if you are Robert Carr, you are likely questioning how RAM scraping attacks can gain access to cardholder data when end-to-end encryption has been implemented.  After all, you have been told that end-to-end encryption is the answer to protecting cardholder data.  Yes, once the data is encrypted, as long as strong keys and proper key management practices have been implemented and are followed, the data is protected.  However, the data is not protected at the end points where the data is encrypted and decrypted.  It is at these endpoints where RAM scraping targets end-to-end encryption.

At some point, the data must be in a format that can be processed and that is what the people that develop these RAM scrapers rely on.  But the cardholder data is only in memory for such a short time, possibly only a millisecond.  Do not be so sure.  Unfortunately, with the advent of high-level languages and cheap memory, memory management is not as well managed as you might think.  We have seen instances of cardholder data being stored in the memory of card terminals and PCs for hours, days and in some very rare cases, forever.  As a result, if you can gain access to the memory of these devices, you can hit the mother-lode in cardholder data.

Now before you go off in a panic, the PCI DSS does have some protections that are already provided.

  • Requirement 1 – Firewalls.  There are a number of requirements in this section regarding the regular review of firewall rules, control of network traffic and other topics.  However, the purpose of these requirements is to respond to the changing threat environment.  In addition, firewalls generate alerts and log data, so these should be regularly reviewed to make sure that a RAM scraper has not been introduced into the environment.
  • Requirement 3.5 – Encryption Key Management.  As long as you follow the recommendations in this set of requirements, your encryption keys should be safe.
  • Requirement 5 – Anti-Virus.  Most of these RAM scrapers are installed through some sort of attack that uses virus and/or malware techniques.  If your anti-virus is up to date and it protects against malware, you will likely be notified of such an instance.  The attack is likely not going to be direct, so you need to make sure that all systems that interact with your cardholder data environment need to be monitored to ensure that a RAM scraping payload is not delivered anywhere in your network.  The key is monitoring.  If you are not actively monitoring attacks, you will likely miss the introduction of the RAM scraper.
  • Requirement 10 – Log Analysis.  If you are properly reviewing your logs, the alerts from your anti-virus and critical file monitoring should be contained in your log data.  The key is that you are conducting log reviews at least daily, if not more often.  If you have a centralized log collection system, I would recommend that you create queries that use criteria to meet various PCI DSS requirements.
  • Requirement 11.5 – Critical File Monitoring.  RAM scrapers are executable files.  If you have configured your critical file monitoring correctly, this new executable will trigger an alert.  However, not all end points can be monitored this way, so you may have to find another approach to protect those devices.  Again, monitoring is the key.

If you are religiously following these points, you should be addressing this new threat as best as you can.

As I have constantly stated, security is not perfect.  So, just because you are following the PCI DSS does not mean that you will not have an incident.  It only means that the impact of an incident will be minimized.


2 Responses to “The Threat Landscape Has Changed”

  1. 1 NRS
    April 16, 2012 at 1:51 PM

    Does Linux systems handling credit card data require Anti Virus software?

    • April 16, 2012 at 2:59 PM


      Reqirement 5.1 of the PCI DSS states: “Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).”

      A lot of Linux “bigots” claim that Linux is not “commonly” affected by viruses and therefore Linux systems do not need anti-virus. The other argument is that anti-virus solutions severely impact performance (you get this from Windows users as well). While to some extent, I can see their points, these are rather general statements that I do not necessarily completely agree.

      I would argue that not all Linux systems are created equal. Some Linuxes such as Ubuntu, SuSE and Fedora, are more susceptible to viruses and malware than less popular Linux releases. However, they all share some common ancestry, so that is not a complete guarantee of operating virus free. In addition, properly configured, hardened and monitored, there are ways on Linux to achieve compliance with 5.1 without using anti-virus, although you would be using a compensating control to comply with 5.1.

      It is up to you to build a business case to avoid implementing anti-virus on Linux if that is the approach you want to take. However, you need to be prepared to still have methods in place that ensure that a virus, malware, etc. cannot get on your Linux systems. You will then have to document those alternative compensating controls in a compensating control document for requirement 5.1 and have your QSA validate those controls.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


December 2009
« Nov   Jan »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,985 other followers


%d bloggers like this: