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.
PCI Guru 
This blog was… how do I say it? Relevant!! Finally
I’ve found something which helped me. Appreciate it!
So, what I take from all of this, is that now, DECT hacking is trivial, due to the availability of old inexpensive hardware. You’ve simply written a “How-To” guide to steal data from any environment using wireless headsets.
You also claim that you would have to pack a van full of old notebooks. What about a Van with a Virtual System, with hosted cards in an external PCMCIA chassis?
You also claim that DECT and Bluetooth are “safer” due to the limitations of the broadcast distance. I suggest that you go read some of the things that have been done in the RF arena at Defcon and similar conferences, where RF ranges have been easily expanded by two orders of magnitude, by simply using better antennas and upping the transceiver power. You may wish to google for “Bluetooth Rifle”
This technology has been around for over 10 years, and simply saying that “It’s difficult because it’s old and limited distance” is a shortsighted viewpoint.
I would seriously consider some other mechanism to at least DETECT and/or PREVENT this type of attack to your call centers where PCI or ANY OTHER critical information is discussed.
That’s just my 2¢, YMMV.
I am not saying it is not possible. I am just pointing out that the hack is not something that could be done as easily as some people believe or have implied because of their “Chicken Little” approach to the discussion.
I also did NOT claim anything. I looked at the risk and made a decision about that risk. Huge difference.
That said, such a DECT or Bluetooth hack would be a hack of last resort in my book. If you cannot social engineer your way into a call center and gain access to the call recording system, then I would highly suspect that hacking DECT or Bluetooth would also be unsuccessful.
Hacking is a business now and it has to have an ROI. A hack of DECT or Bluetooth requires more investment than I think most attackers would want to invest. The target involved would have to have a HUGE payoff which I would have to say that the call centers I have dealt with would not provide the return that hacking a bank or another more lucrative target would provide and would probably be easier.
Obviously, I have given you your new Black Hat discussion topic. I will be interested in seeing if you can put together a believable attack that could actually be profitable.
Mr. PCI Guru, this is a great discussion, and one in which I agree with you. I like your risk based approach, and agree that companies should be able to analyze their own scenario, be forward with their acquiring bank, and come to an agreement with them. At the end of the day, the risk is between the acquiring bank and the merchant, regardless of what a QSA says.
Instead of worrying about DECT handsets where an attacker can listen for hours or days to hear a handful of credit card numbers, companies should be focusing their controls, time and resources on methods to detect the large scale breaches… not an attacker listening to 24 hours of a call center representative to capture 10 credit cards.
Could not have said it better.
Any call center is going to have gobs of non-public information in every call that can lead to identity theft.
For businesses only interested in bare-bones compliance (short-term cost control) and not protection of all confidential data they hold about customers (long-term cost control), this works. It’s also why so-called “PCI compliant” companies keep getting breached. Compliance != security and in fact compliance < minimum security.
Elements of this discussion really drive home what PCI 3.0 BAU (business as usual) means in practice: Argue down the risks, brow-beat the QSA into agreeing with your assessment, and make sure your personal assets are not affected by the breach that leads to the closing of your company. Yes, business as usual indeed.
But if a client approached with a reasonably reasoned argument as to why DECT or any wireless headset was not an issue, that would have to be assessed by the QSA and a determination made. If the client and QSA do not agree, then the acquiring bank needs to make the call. But at the end of the day, there are too many QSAs that want to take the easy way out and just declare a technology “verboten” because it would take effort to make a determination, let alone hanging their neck out saying they accept the client’s rationale.
That said, I really think the risk of a DECT headset being used as a breach point is silly. Can it be done? No doubt. Would an attacker get enough information to make all of the work required worthwhile? I doubt it. Just as companies have ROI requirements, so do attackers. But in the case of businesses and attackers, there are always going to be those outliers that do silly things just for the sake of doing silly things.
Just worth noting that the ranges you quote are the ‘official’ ranges – anyone can extend these with the right equipment, as shown here: http://www.npr.org/templates/story/story.php?storyId=4599106 Same applies for DECT, just need the right amplifier and filters, and you can capture the signals. Decoding them might be a bit more difficult, but I can think of a number of ways around the hardware restrictions you note above.
Does this mean we need to strap a Faraday cage on the heads of each call centre operator? Almost certainly not (although I have dealt with a few call centre people who I would suggest deserve such a fate). But we do need to be open to the fact that interception of the data is easier than you might think. At the very least, I would expect a CC work sheet on this sort of thing, demonstrating a sound understanding of the risks and how they have been mitigated.
Agreed. But is it realistic given that you can only snoop on one headset at a time? No doubt there are fools for thieves that will try this, but the amount of data retrieved would likely be minimal.
Although I agree with your risk assessment of the DECT headsets. That does not change the fact that they are not PCI complaint. All that your risk assessment buys you is lawyerise for a mitigating control. This means that you will have to replace the headsets with a PCI complaint product at some point in the future. You might get 1-3 years of not doing anything more other than “evaluating potental PCI complaint headsets for replacing the DECT headsets.” Then maybe another 2-6 years of “replacing DECT headsets with PCI complaint headsets as the DECT headsets wear out or become damaged.”
So essentally document what you know and what it means. Then have a plan of action and show progress relative to the weight of the meaning.
But that is what security is all about. Assessing risk and determining if you can accept the residual risk that remains after you mitigate as much of the risk as you can.
Technically, all wireless technologies are at risk because they operate in an arena that can never be trusted because anyone can “observe” it without the knowledge of the user. WPA2 Enterprise relies on 802.1X authentication and I would think most people would view that solution as secure. However, it only requires the compromise of the directory system used to authenticate users or a flaw in WPA2 to be discovered to make that assessment moot.
But let’s not go there on the “PCI compliant” headsets, okay? Talk about adding FUD to the process. Is that really what we want in life? Another standard to assess wireless technologies for PCI compliance? Do you really want people shopping around for “PCI compliant” smartphones to use with their Square or other mobile payment terminal solution?
Normally I have a great deal of respect for your opinions and guidance but I think you kind of missed the boat on this one. You seem to be taking the position that DSS applies, but, “Shhhhh, let’s pretend it doesn’t because protecting these things would be too hard”. If there’s one thing attackers have taught us, it’s that yesterday’s impossibility is today’s attack. The same things you mentioned about DECT used to be said about memory scrapers and cell phone towers
>> You would need as many rogue devices as actual headsets to surreptitiously pair with each individual headset in order to get the conversations.
Isn’t that like saying, although on a smaller scale, that it’s OK to have only one compromised POS devices in a store because you’ll only get some of the card numbers and not all of them? Wasn’t that what happened to Barnes and Noble? Didn’t Home Depot initially say their hack wasn’t that big a big deal because only the self-service checkout POS devices were compromised? How well has that worked out for them?
> 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.
Really, a sample size of one is valid? Put yourself into Remediation. 🙂
Is your home on the top floor of a very large building and all of the walls are actually huge windows? Our call center is. And it’s surrounded by apartment buildings. I’ve got decades of RF experience and your statement reminds me of the proclamations that Bluetooth could not be a risk because it only had a 6-foot range. Not only did the Bluetooth equipment improve over time, so did the antennas and interception equipment. Same with Wi-Fi. The record is now, what, over a hundred miles for a consumer Wi-Fi device?
The headquarters for an extremely large insurance company in this area uses DECT headsets but when they rebuilt their call center, they copper-screened the walls and ceiling and added protective film to the windows. They also used a spectrum analyzer outside the call center to survey the area for leakage and do so on a routine basis. None of those are activities undertaken for a minimal risk issue.
If you have wireless technology in the CDE, you need a compensating control if it is not compliant. I haven’t found a single company that even manufactures DECT detection equipment much less a wireless IPS for it. Suggestions for compensating controls to protect the confidential data in that phone conversation would be appreciated.
I get it that you’re a consultant and working for a new company so you need to play by their rules. That’s not stopping Didier Godart from giving away his PCI spreadsheets. They know people will look more favorably on his company and that can lead to collateral business.
Obviously your willingness to accept risk is not as great as mine. And I am not say or even implying it is out of scope, I’m just saying let’s think it through and then document things accordingly.
But are headsets actually part of the CDE or only “connected”? In my opinion, they are connected, a conduit to the CDE which would include the call recording system. At times they may transmit CDE, but that is the extent. Following your logic, POTS lines and VoIP are easily tapped, so what have you done to mitigate that risk? Connected your VoIP directly to your carrier and invested in a VoIP firewall? You realize of course that the bulk of VoIP is stateless (i.e., UDP), so a firewall does nothing to protect VoIP even though the firewall solution vendors will tell you otherwise. Still trying to figure out how they can tell a “bad” streaming audio/video packet from a “good” one.
At some point we need to draw a line somewhere because security is all about preventing/mitigating 98% of the risk and managing the remaining 2%. And that last 2% is a bitch to mitigate unless you have management that are willing to spend the hundreds of millions it will take to even come close to mitigating it.
If you want to chase your butt down this rabbit hole go ahead but you can do it without me.
Maybe I’m misunderstanding the technology, but this seems like a red herring. Wireless headsets only pair (connect) to one thing at a time. As soon as the headset makes the connection to the rogue device, it’s no longer connected to the phone system, or the customer, or anything involved in the business (or cardholder data). The hacker might hear the agent say “hello? hello?” but the call is over at that point.
The only way this makes any sense is a spectrum capture device that can surreptitiously capture all the encrypted bits streaming from the base station to the headset, and record it for posterity.
If I interpreted the limited documentation available, the “deDECTed” software allowed the pairing of the DECT device to the computer and then the computer to pair to the real base station in a man in the middle fashion. That was in addition to “sniffing” for DECT frequencies which is how an attack would most likely occur. It is comparable to packet capturing of VoIP traffic with WireShark on a mirrored/promiscuous network port and then running those packets through software to reassemble and playback the conversations. The BlueSnarf and similar attacks on Bluetooth work the same way by “pairing” to Bluetooth devices and then grabbing the traffic and putting that traffic through software to either play it as audio or convert it to data streams.