Capturing administrative credentials as a path to stealing sensitive credit card data is becoming a more common method used by cybercriminals. It is not surprising, then, that the PCI Security Standards Council would address this rising threat in the new version of the PCI Data Security Standard (PCI-DSS). For some time now the PCI council has been telling merchants, service providers, and banks that it would more aggressively respond to emerging threats, and version 3.2 of the PCI-DSS standard reflects this.
A password is something you know, so the second factor for authentication must be something you have such as a cell phone or token, or something you are such as a fingerprint or iris image. Secret questions don’t qualify as as second factor as they are also something you know, like the password. A general description of two factor authentication can be found here.
Prior to version 3.2 of the PCI Data Security Standard, remote users were required to use two factor authentication for access to all systems processing, transmitting, or storing credit card data. With version 3.2 this is now extended to include ALL local users performing administrative functions in the cardholder data environment (CDE). This makes sense as user PCs can be infected with malware that leads to the compromise of administrative credentials. It hardly matters anymore if the user is local or remote.
Why is this a big deal?
First, many companies processing credit card data do not have remote workers, and 2FA will be new technology. Even if you have remote administrators, they are probably authenticating with 2FA via a VPN session which will not work with internal administrators. This means evaluating new 2FA solutions, deploying them in all of your CDE environments, training employees on how to use the technology, and implementing new HR procedures to manage employees and access to 2FA.
Second, many 2FA solutions require deployment on hardware servers that must be deployed and maintained. There may be impacts on the company network and firewalls, and it means a new technology ramp-up. This includes addressing hybrid environments that may encompass traditional IT data centers, virtualized environments, and cloud applications. If the 2FA solution is based on hardware tokens that employees have to carry, you will have to manage the distribution, revocation, and replacement of tokens.
Third, many merchants have complex cardholder data environments and a 2FA project can be daunting. Think about a large box store retailer. Besides the normal check-out Point-of-Sale systems, they might have pharmacy, optical, automotive, and many other departments under the same roof. The CDE might be complex and extensive and the 2FA effort may be large depending on how much administrative work is performed locally.
Last, it is not enough to deploy a 2FA solution. It must be properly monitored in real time. An attacker may attempt to guess or brute-force attack the PIN code. A good 2FA solution will log both successful and unsuccessful PIN validation requests. The logged failures should be monitored by a SIEM solution so that the security team can react to the threat quickly.
Here at Townsend Security we provide a solution to IBM i (AS/400, iSeries) customers that is based on mobile, voice, and optional email delivery of PIN codes. Alliance Two Factor Authentication integrates directly with the global Telesign network to deliver PIN codes. A customer who needs to deploy two factor authentication can install, configure and verify a 2FA PIN code sequence in less than 30 minutes. There is no hardware to install or maintain, and there are no individual tokens to distribute and manage. We think that this solution will help many IBM i customers quickly achieve compliance with version 3.2 of PCI-DSS and PA-DSS. More information here:
In future blogs I will talk more specifically about our solution.
Patrick