A QSA apparently posed a question to the Council regarding the scope of wireless headsets used in a client’s call centers. In this case, the headsets rely on DECT technology. The response from the Council was as follows:
“Although DECT is not specifically referenced in PCI DSS v3, it is a digital wireless telephone technology and given the scenario you are describing, PCI DSS requirement 4.1 and 4.1.1 would apply.”
The resulting LinkedIn discussion surrounded whether the DECT headsets are in-scope which, of course, they are in-scope. However, the implication of the discussion was that, if in-scope, could the DECT headsets be considered as PCI compliant. Let us walk through a discussion of this issue and develop a position on whether or not DECT headsets are a risk and can they be considered PCI compliant.
For those of us that do not have the PCI DSS memorized requirement 4.1 states:
“Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
- Only trusted keys and certificates are accepted.
- The protocol in use only supports secure versions or configurations.
- The encryption strength is appropriate for the encryption methodology in use.”
Requirement 4.1.1 states:
“Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.”
For those of you not up on DECT, it does not rely on strong encryption as defined by NIST and other recognized sources. The encryption used is 64-bit, almost as lame as DES. But it gets worse; the protocol does not require the use of a secure authentication method to pair devices to their base station. As a result, it is relatively easy to force authentication to a rogue base station. To add to the threat, the theoretical transmission distance is 500m or around a third of a mile. So it has the capability of transmitting fairly long distances.
Sounds like a PCI and general security train wreck does it not?
Now before we all go off and tell every one of our call center clients that DECT is no longer allowed, let us all take a big deep breath and look at this issue clearly.
The first question that should always be asked is what the real world likelihood of such an attack is. In this case, would an attack on 20, 50, 100 or more DECT headsets make sense? Probably not and here is why I believe that to be the case.
You would need as many rogue devices as actual headsets to surreptitiously pair with each individual headset in order to get the conversations. This would require a large van with racks of notebooks in order to accomplish such an attack. And that assumes that the transmission distance quoted in the standard can be relied upon. However, based on the use of my own DECT phones at my home, I can tell you that my phones have issues 30’ away from my house, let alone a third of a mile away.
If that isn’t enough, the DECT cards required are no longer manufactured. If you are lucky, you may be able to get them on eBay from Europe for about $25€ or $30USD. I would take this as a good indication that DECT hacking was not a big thing. But it does get worse; the cards use the PCMCIA interface (superseded in 2003) and, according to the limited number of eBay sellers, do not work reliably for hacking DECT when using the requisite adapter cables for connecting them to modern computers via USB. As a result, the hack will also require a large number of old notebooks to execute.
The final nail in this coffin is that the known software exploit, ‘deDECTed’, appears to have languished in development (most likely because of the situation with the PCMCIA cards) and was only included in one distribution of BackTrack, now Kali Linux. You can still download it, but without the requisite hardware, you are pretty much at a standstill.
While all of the tools exist, is this threat realistic? Why would someone go through all of this effort when, in all likelihood, it would have been probably a thousand times easier to hack the call recording system? Hacking the call recording system would skip all of the rigmarole of surreptitiously going after the headsets and skip straight to searching the recordings.
In my opinion, while there is a threat, the risk of that threat occurring is low. Based on this analysis, I would feel comfortable judging these DECT headsets as being PCI compliant and would provide this analysis in my work papers so that reviewers could understand my rationale.
However, this is me talking from my willingness to accept this risk. Other people and organizations might not be quite so willing and may decide to not allow DECT headsets or phones. That is their decision but it should be made with information and discussion such as was provided here and not in a vacuum as a “knee jerk” response.
By the way, this technique of capturing people’s conversations is much easier to do with Bluetooth and such tools exist in Kali Linux to accomplish that attack. However, the same issue of one rogue device to one Bluetooth device still exists. Good news there, Kali Linux is available for smartphones, so you only need a lot of smartphones to execute the attack. That is mitigated by the fact that the distance for Bluetooth is only 30’ or 9m. So as long as a call center enforces a policy of no personal or foreign technology on the call center floor, then any headsets should be safe.
The take away from this post is to think through the implications of the Council’s directives before you go off advising organizations that certain technologies are not PCI compliant. While I agree with the Council’s answer to the question, it did not immediately mean that the technology was now verboten just because the technology’s basic characteristics appeared to make it non-compliant. QSAs and organizations need to assess the threat, the risk of the threat occurring and then make a decision as to whether or not that threat is something to be managed or avoided.
