In case you missed it, the PCI SSC released their new information supplement on telephony this week. Since I served on this Special Interest Group (SIG) I was involved in its development. As a result, I thought I would share my thoughts on the new information supplement.
A Bit Of Background
At the start of the SIG a number of participants brought up the fact that the prior Telephony Information Supplement issued in 2011 had basically been ignored by the qualified security assessor (QSA) community and companies being assessed. A number of QSAs and Participating Organization (PO) representatives explained to Council representatives that they had personally witnessed situations where QSAs ignored voice over IP (VoIP).
That brought about the following response from one of the Council members on the call:
“All QSAs are trained to understand that VoIP is in scope if CHD/SAD [cardholder data/sensitive authentication data] is discussed on any telephone calls.”
The consensus response was that while that is no doubt the case, many participants attested to the fact that they had encountered QSAs ignoring VoIP as being in scope. Some had witnessed QSAs telling their clients and prospective clients to not worry about VoIP because it will not be in scope. These same QSAs did worry about the security of call recordings, but they were leaving the rest of telephony out of scope.
That response seemed to send a chill through the Council representatives. No one identified any particular qualified security assessor companies (QSAC) but the participants made it clear that VoIP was largely being ignored in PCI assessments. The point was also made that some QSACs were benefiting handsomely in obtaining engagements because of their willingness to ignore VoIP.
But that exchange also identified a shortcoming with today’s telephony solutions. QSAs and technology people do not seem to understand telephony solutions and appreciate their risks. Therefore, they do not know where to even start in securing them let alone those that make an attempt only to find themselves in one or more “rabbit holes”. As a result, it is easier to ignore these telephony solutions than to try and deal with the intricacies and vagaries of securing them.
There were also brief discussions about the shortcomings of the original information supplement from 2011. The biggest complaint of which was that it was call center centric and did not reflect what was being implemented in the real world. Various people explained that the 2011 document did not address call centers operated within corporations on a shared telephony solution with the rest of the business nor was there any useful guidance provided for PCI compliance.
Such configurations obviously complicate the scope of PCI assessments since any device connected to the shared VoIP system and network was therefore in scope (hence why a lot of QSAs ignore VoIP). As we were to find out, the new version of the information supplement would do only a little to address this complex issue.
Disappointment
Trust me, it was not the SIG’s intent nor the Council’s intent to disappoint people, but I have a feeling that a lot of people will be disappointed with this information supplement. Not that there are not good ideas and solutions presented, they are just not always as fleshed out as well as they should be and do not always represent what actually goes on with the solution. The reason is for that is because telephony solutions all operate differently when performing various functions such as call forwarding, conference calling and the like. As a result, providing real guidance depends greatly on how a given solution functions in a particular circumstance. As we found out a number of times, this issue would come back to bite SIG participants repeatedly.
In my very humble opinion, the latest information supplement is lacking in detailed guidance to a lot of telephony situations particularly those that are complicated because of how vendors have approached Unified Communications which is the driving force now behind most vendors’ current telephony solutions. The document points out a lot of scope and security concerns regarding the use of softphones and VoIP only to leave the reader essentially up to their own devices as to how to address those concerns using existing guidance from other information supplements.
That was a point of contention as the information supplement was developed. There were a number of people that argued that more guidance was needed to be provided because the issues are more complicated and nuanced than the supplement leads people to believe. They wanted more discussion with the card brands about the risks involved so that all parties could come to a consensus over what was acceptable risk and if there were better ways to address those risks and therefore provide more guidance. Unfortunately, we were told that there was not enough time to have such discussions which drove in great part what resulted in the document that you now have access.
Then there are the threats to VoIP that seemed to be minimized in discussions. At one point in a meeting someone stated that VoIP is not an attack vector so there is no need to worry about it. This individual was almost immediately reminded that this is how we got into this situation in the first place. People ignored the risks to processing, storing and transmitting payment card data and then we all had to do a fire drill to secure that information.
Using CVE Details, I was able to identify close to 400 specific threats to VoIP and/or specific VoIP vendor solutions. Of those, there were around 250 to 300 that appeared to be able to compromise VoIP and by association, CHD/SAD. While most had been patched, there were a around 20 that had no fix because they were flaws in the protocols themselves (mostly due to UDP streaming). The bottom line in this research is that while VoIP might not be an active attack vector at this point in time, it is ripe for being turned into one. Worse, current information security practices have minimal effect on a lot of the attack vectors thanks to UDP. And if that was not bad enough, in a lot of cases all it takes is a telephone call to start the attack process.
With that as a background, while the new information supplement is a quantum leap above the 2011 information supplement, a lot of participants feel it is still somewhat lacking in guidance.
Telephony Guidance Anger
I can already anticipate the anger that will result from this one particular recommendation on page 55, section E.4 Unified Communications, where it states:
“As a result, entities can find that their only option to minimize the PCI scope of their VoIP environment is to implement multiple instances of in scope VoIP and out of scope VoIP.”
Say what?!?!?
That will be a huge burst of a bubble to a lot of organizations, QSAs and ISAs alike. The rationale for this statement goes to Unified Communications and how most vendors have approached it. The telephony system vendors have now so tightly integrated services such as voice, voice mail, facsimile, video, telepresence, instant message, email and other communication mediums that it has resulted in an inability to decouple and move say instant messaging or email to a different network segment from the call manager. As a result, there are no easy ways to implement network segmentation around telephony solutions so that some are in the CDE (Category 1) and others are in Shared Services (Category 2).
Unfortunately, Unified Communications is not the only situation where two telephony solutions will be needed. Softphones, call centers on common corporate telephony solutions and other telephony features/functions will also create situations where the only way to be PCI compliant will be to implement at least two separate telephony systems.
Speaking of softphones, if you were angry at the first statement, your anger will likely only grow when you read the following on page 24, 5.2.4 Softphones:
“It is important to note that the use of such systems [softphones] to capture payment card account data would bring the workstation and probably the network it is connected to into PCI DSS scope.”
The next paragraph after the quotation points readers to the Network Segmentation Information Supplement for guidance. Unfortunately, the problem with that guidance is that regardless of how you try to segment the workstation, the softphone application will put the workstation in scope regardless. No other guidance is provided regarding softphones. It is not like this was not discussed within the SIG, it is just that there was no agreement on how to address this subject. So, what you read in this section is the guidance you get.
One potential solution discussed to minimize scope is to put the softphone in a virtual desktop (VDI) workstation. That would put the VDI in the CDE and the workstation as Shared Services. However, the VDI approach can be fraught with compatibility issues and other technical problems that may not reliably provide telephony service to end users via the softphone. There is also still some risk of eavesdropping through the end user’s workstation, but it is now limited to memory in the workstation versus the softphone software that can sometimes be addressed with other workstation controls. This of course is assuming that the VDI solution is easier to control, secure and monitor than the physical workstations. The bottom line is that there are a lot of moving parts that would have to be assessed on a case-by-case basis, so the consensus was that there was no general, one size fits all recommendation that could safely be made about the VDI approach.
Another scope reduction approach is to use “inexpensive” physical SIP phones for handling calls that are logically network segmented away from the workstation. I have a number of clients with agents configured this way to limit telephony scope to just their SIP phone. But then their router must support two VLAN connections and those VLANs cannot be allowed to access each other. That is easy to do in a corporate environment but can complicate things with SOHO workers. Such a solution can drive up networking and equipment costs to an unacceptable level for some organizations. Particularly organizations that were looking at softphones to reduce costs.
There are plenty of other areas of the information supplement that will generate anger mainly because for the first time, the PCI SSC is calling out more areas that are in scope for PCI compliance that organizations and some QSAs/ISAs treated as, or thought were out of scope.
Miscellaneous Comments
There are a few more points that I felt should be discussed.
On page 43, 7.2.2 SIP Trunking, the following quote will be of interest.
“As the technology matures, technical boundaries between an organization and SIP Trunk provider may become harder to define. Scoping for these services will therefore require an understanding of how connections are made between the different entities.”
I feel this is already an issue because the boundaries are already blurred. When you realize that VoIP is predominately a UDP protocol, there is little you can do from an information security point to protect your telephony system.
First the carriers will tell you that their SIP demarcation device will provide some amount of security for your organization. Exactly what amount of “security” that device actually provides is questionable at best.
But speaking of UDP, page 54, E.1 Protocols, Ports and Network states the obvious.
“… the use of UDP may render the detection of malicious content or payload more difficult.”
More difficult? In some ways, it can be impossible to detect malicious payloads because it is streaming, and you want to ensure continuity of a conversation. This is the biggest security issue with VoIP, because it relies on UDP streaming, VoIP exploits use that stateless streaming to their advantage by embedding the attack in the voice/video stream.
This inevitably brings up the discussion of firewalling your VoIP because that seems to have been the answer for every other security issue. While the firewall will provide some amount of control and monitoring of TCP connections, it will do nothing for the UDP streams that VoIP relies upon.
Yet I have actually had some firewall vendor sales people claim that their firewalls are “VoIP aware” and can identify certain “bad” VoIP packets. I’m not sure exactly how you can identify bad UDP audio/video data streams, but they claim to have some sort of proprietary methods for doing just that. Of course, when you attempt to drill down on that “proprietary method” you get essentially stonewalled because it is “proprietary”. I take that as an indication of sales “smoke and mirrors”.
Then there is the solution of encrypting all VoIP traffic. I have had a number of clients suggest this as a solution to the security of telephony. While encryption of all VoIP traffic minimizes the ability to eavesdrop on calls via the network, it does not remove the risk of eavesdropping via compromised endpoints which is much greater than the network risk. Encryption also does not remove the risk of malware injected via the UDP stream which is the bulk of the real threats to VoIP. After all of the discussion surrounding encryption, I really see only marginal value in the use of encryption of VoIP traffic from a security perspective.
Also, on page 54, E.2 VoIP Attacks and Vulnerabilities you get this statement.
“VoIP equipment and software are susceptible to vulnerabilities that could allow someone with malicious intents to gain access to your network, intercept and gather customer data, or initiate a Denial Of Service attack.”
I cannot tell you how many IT professionals do not realize the risk presented by VoIP and its infrastructure. They seem to treat it like the PABXs of old that used to be located in basements next to the telephone carrier’s point of presence (POP) at their organization’s facilities.
Granted, we have moved away from the Windows and Linux versions of call managers that were standard fare when VoIP originally came out. Most of today’s call managers are based on some proprietary derivative of Linux or Unix stripped down and modified for telephony. But there are open source solutions that run on Windows and Linux server editions. The bottom line though is that regardless of what you run, these are still servers no different than any other servers and they need to be properly configured and get regular patching just like any other server.
That is my take on the latest telephony guidance from the Council. Better than what was produced in 2011 but still lacking in some areas.
PCI Guru 
Gotta love the introduction with the usual bitching and whining from assessed entities about how assessors are ignored VoIP. Guess what, determining the scope is the assessed entities sole responsibilities. The QSA’s role is simply to validate that the scope was reasonably established.
So assessed entities will voluntarily ignore VoIP to minimize assessing costs which is understandable but then having these same entities complaining about it to the Council is simply laughable.
If assessed entities were willing to pay, QSA’s would even include the kitchen sink and the coffee maker. A bigger scope = more revenues for QSA’s so they should not be blamed when assessed entities are voluntarily excluding key components from the CDE.
While the assessed entity is responsible for defining scope, the QSA is responsible for confirming the assessed entity’s scope. So, it is the responsibility of the QSA to identify that VoIP is in scope and that the PCI scope is NOT correct.
I’m happy for the clarity that the new document provides with respect to VoIP.
However, I’m still confused:
1) Why are “carriers” not classified as service providers?
2) Why is POTS service is not considered in scope, ie “carrier” is service provider and merchant has some responsibility to check for tampering (at least to the DEMARC), etc?
3) Also, if I continue to get phone service from a “carrier” and regardless of how they supply the phone line to my small business then I assume the phone line is not in scope, correct? What I’m describing looks like diagram 1 on page 6, but there will be either two or three lines. This case is fictional and for discussion sake.
From a risk basis, I believe phones, before VoIP were and still are a serious vector. There’s no real active detection methods for phone taps on POTS lines. Typically there are lots of places to install taps but not the same everywhere. This is not anywhere near as bad as gas pumps used to be. However, tapping POTS lines might become low hanging fruit.
In general, I believe VoIP when configured properly is better than POTS, etc. HOWEVER, I don’t want to subject VoIP infrastructure to the complete PCI DSS.
Thanks,
Oskar
Carriers are service providers IF they are providing more than just dial tone.
There really is no more plain old telephone service (POTS) in the sense of analog service. Even to peoples’ homes, the service delivered to the pillar is likely VoIP. Once that service crosses the carrier’s point of demarcation (demarc), it is your organization’s responsibility to secure it. It has been that way since day one with the PCI DSS.
Just to confirm that the telephone service carrier is out of scope if and only if all they are providing to your organization is dial tone.
Sorry, but if your VoIP is used to discuss sensitive authentication data (SAD) or cardholder data (CHD), then the VoIP system is in scope for PCI compliance just like any other applications and related infrastructure. It has always been that way, it is just that the new information supplement is making that even more clear than the prior supplements it replaces.
Hi.
Maybe a bit off topic. But surely the perfect solution for these businesses who do not want the VoIP solution in scope would be to implement a DTMF solution. Taking the requirements directly away from the business and dumping them on the service provider.
DTMF does not always take the company’s VoIP out of scope as it depends greatly on how the solution works. A lot of DTMF solutions still leave the call manager in scope. The operator cannot hear the tones being keyed, but the call is still going through the call manager. Therefore SAD/CHD is still transmitting through the call manager.
Vulnerabilities do not equal attacks which also do not equal breaches which, again, do not always equal intolerable fiscal losses. As you stated, no known breach or loss from VOIP weaknesses have occured. This makes liklihood an extremely remote probability. Wise decision by the PCI council to avoid recommending dollars to protect dimes.
“This makes liklihood an extremely remote probability.”
That is the problem. People write off the threat as though the probability is low because it hasn’t occurred or has only occurred a limited number of times. It’s only a matter of time before people start using these vectors if they haven’t already. Given it’s UDP, it could be highly likely that they have been used and organizations just don’t realize it yet.