Payment processing infrastructure is vulnerable to cyberattacks, just like any other piece of the technology puzzle. With this in mind, at Amazon Payment Services we make a significant effort to protect our payment processing infrastructure and our customer information from cyberattacks. In addition to being certified to PCI-DSS Level 1, we have a dedicated information security function focused on continually advancing our security capabilities.
In this case study, we’ll examine how Amazon Payment Services responded to the threat of a vulnerability in Log4j and consider the steps we took to protect our systems against similar emerging vulnerabilities.
What Log4j is used for
The systems that process card payments are built on top of common technology components (server operating systems, web servers, etc.), with a specific purpose for each system. For example, as per PCI-DSS requirements, payment processing requires server activity logging, and commonly available tools are customized for this purpose.
Log4j is a software development building block that is widely used by companies across industries to keep track of everyday transactions in online services or software applications. Here at Amazon Payment Services, we rely on a customized version of Log4j to log activities across our systems.
In December 2021, a critical vulnerability in Log4j was disclosed and companies using Log4j were susceptible to this vulnerability. In other words, a flaw in the Log4j code emerged, a flaw that could be exploited by cybercriminals.
Why we were concerned about the Log4j vulnerability
At Amazon Payment Services, we received a security alert about the vulnerability in Log4j as soon as it was discovered. As is usually the case, the vulnerability was also publicly disclosed, meaning that the bug in the source code was published and could be exploited by cybercriminals.
We quickly noticed that, unless mitigated, Log4j would be a dangerous vulnerability because it could enable an attacker to remotely control unsecured systems by sending malicious data in web requests. The simplicity of exploiting the Log4j vulnerability alongside its potential consequences made the potential risk of attack very concerning.
An established mitigated process for Amazon Payment Services
We have an established process to deal with major cybersecurity alerts because we know that a structured, rapid approach is critical when security vulnerabilities come to light. It was exactly this approach that was taken when our team discovered the Log4j threat via our threat intelligence resource.
Our approach consisted of several key steps. First, we gathered information about the vulnerability and investigated how it could be exploited. The aim here was to understand the methodology of potential attacks and to examine how the vulnerability interacted with our security controls.
Next, we followed our remediation process. Our preference is to quickly install an update to fix the vulnerability, but until that update is available we apply additional security controls to mitigate potential attacks in the interim.
During this interim period, we proactively monitored our systems while also reaching out to our partners to ensure that their systems were also protected against this recently discovered vulnerability – to ensure that end-to-end services remained available.
Due to this established process, Amazon Payment Services security team wasted no time in mitigating risks around the Log4j threat once it was discovered. As per our incident response process, we immediately updated our web application firewall to block attempts at exploiting the new vulnerability and intensified monitoring to observe exploitation attempts from cyberattackers. We also reviewed our logs and found no evidence of impact to any customer data.
Once the solutions were available, we moved rapidly to update the affected program Log4j code. Although the updates were released through 3 subsequent patches to mitigate the risk, we moved swiftly to apply these patches as soon as they were available.
What this means for our customers
Our Amazon Payment Services team showed extreme bias for action by rapidly updating our systems to counter this vulnerability, three times in rapid succession. We also enhanced monitoring against related exploit attempts as soon as the vulnerability was disclosed.
By reacting with necessary speed, we minimized the window between the public disclosure of a vulnerability and the opportunity for cybercriminals to exploit that vulnerability. This case study outlines how we protect our systems against vulnerabilities, and demonstrates the importance we place in securing our customer data and payment processing workloads.
