Archive for the 'information supplement' Category

18
Aug
17

Why Voice Over IP Matters

“Voice over IP are the most insidious set of communication protocols ever invented by man.” – Jeff Hall

I have been having some interesting conversations of late with prospects and clients regarding Voice over IP (VoIP).  These conversations all seem to revolve around whether or not VoIP is in scope for PCI compliance.  Ultimately the conversation turns to a discussion of why I believe VoIP is in scope for PCI and almost every other QSA seems to never bring the subject up.

The primary reason I believe VoIP is in scope is that the PCI SSC says so.  If you read FAQ #1153 titled ‘Is VoIP in scope for PCI DSS?’ the Council makes it painfully clear that VoIP is definitely in scope if VoIP transmits sensitive authentication (SAD) or cardholder data (CHD).  If you doubt it, here is the exact quote from the first paragraph of that FAQ.

“While PCI DSS does not explicitly reference the use of VoIP, VoIP traffic that contains cardholder data is in scope for applicable PCI DSS controls, in the same way that other IP network traffic containing cardholder data would be.”

Yet even when it is stated that clearly, I still run into people that claim I am making a mountain out of a mole hill and their VoIP is not a risk because other QSAs have never inquired about it.  What that merely means is that other QSAs are ignoring it when they should not be ignoring it.

The first problem with VoIP seems to be that very few people understand it which is the biggest reason in my opinion that a lot of QSAs avoid the discussion.  But it is not just QSAs.  I speak with network administrators, information security personnel and other technology people all of the time and if there is one topic that will glaze over all of their eyes, it is VoIP.  When the discussion turns to VoIP, people seem to hark back to that old PBX system tucked away in the basement or closet.  No one seems to remember that the PBX did get updates (usually two or three a year).  All anyone remembers is that it just worked and that it got replaced once, maybe twice, in a generation.  And the biggest risk was toll fraud from the Caribbean.

But scarier yet is that these people do not seem to completely understand how VoIP and its protocols work let alone the risks.  The biggest problem with VoIP are the protocols used and the reason for my quote at the start of this post.  Regardless of whether you are talking SIP, H.323, H.248, whatever, they all operate the same.  Call set up (start of a call) and call tear down (end of a call) are the only points of a VoIP telephone conversation that are stateful, i.e., conducted via TCP.  The actual call itself is all done via streaming UDP just like any other audio/video stream.  Adding insult to injury, VoIP also requires a large number of the ephemeral UDP ports above 32767 to be open.  UDP, being what it is, provides one of the best transport mechanisms for delivering malware.  There are hundreds of exploits for VoIP from the most benign DDoS attack to turning a VoIP telephone into a spying device by surreptitiously enabling its microphone and video camera (if it has a camera).  But my personal favorites are the attacks that use the VoIP network as an entry point into an organization’s data network.  The bottom line is that the only way to firewall any of the VoIP protocols for actual protection is to keep them away from the rest of your network.

But it can and does get worse.  Add in VoIP trunks from your telephone carrier and you really begin to have a recipe for disaster.  When you have VoIP trunks from your carrier, your internal VoIP network is really only protected from every other VoIP network by the carrier and your call managers.  It is that sad fact that keeps a lot of information security professionals up at night.  If security is all about your weakest link, how do you protect yourself and minimize your risk when your weakest link is essentially the entire world’s phone systems?

Let us add insult to injury in this tale of woe and bring in the concept of unified communications and its primary tool, the softphone.  A softphone is software that turns a PC into a telephone using VoIP. All users need is the internet and a VPN connection to the office network and they have their office telephone right there no matter where they are in the world.  However, the softphone opens up that PC to the same risks that exist for every other phone using that call manager.  But if your VoIP system is used to take calls that discuss cardholder data (CHD), you have now turned that PC with a smartphone into a Category 1, in-scope device because it is now connected to a Category 1, in-scope system and network.  Suddenly all of that effort to achieve PCI scope reduction flies right out of the window.

But this all gets the more fascinating as people go back to their VoIP vendors and find out even more troubling issues with their VoIP solutions.  I remember numerous conversations where people thought once a call was connected to a phone that a call manager was no longer involved therefore the call managers could be put on a different network segment, only to find out that call managers act as bridges when calls are conferenced, involve telepresence or they are to/from outside lines.  They also find out that with the advent of unified communications, services such as instant messaging and email integration are no longer separate servers/functions from the call manager and cannot be easily segmented from the call managers to take them out of scope.

But then there is the revised draft version of the VoIP information supplement from the PCI SSC.  Great guidance if you have a call center.  Worthless for any other sort of implementation of VoIP.  It treats VoIP as a discrete operation as though only the call center model exists for VoIP implementations.  Granted call centers are the largest risk when they are in scope because their call volume is typically 80%+ of calls involving payments.  But all sorts of organizations take payment information over the phone but are not a call center model.

So, what about the organization that has call centers and also normal business people all on the same system?  Based on the information supplement, every phone is a Category 1 device unless the call center VoIP system is separate from the rest of the organization.

Must the call center be on a separate VoIP system from the other users?  It would appear to be that way to manage scope.  But again, there is no explicit guidance for any other implementation model other than a call center.

And if the other users take overflow calls from the call center or occasional calls dealing with PAN, how would separate systems help with that situation?  Near as I can tell, it does not help.

And what about unified communication solutions?  No idea as the information supplement does not reference a unified communication solutions.  However, given the whole premise of unified communications is that it is tightly integrated in most VoIP solutions, other communication methods such as instant messaging and telepresence would likely be in scope as well for PCI compliance.

The bottom line is that the advice I provided over six years ago in this blog is still accurate today.

Advertisements
11
Feb
17

The Council Gets A Clue

Late this week the PCI Security Standards Council issued a new information supplement titled ‘Multi-Factor Authentication’ after the brew-ha-ha that occurred last fall at the Community Meeting in Las Vegas.  For once, the Council has issued an excellent reference regarding the issues of multi-factor authentication (MFA).  Although I still have a couple of minor bones to pick about this document, but more on that later.

If you understand the concepts of MFA, you can skip through the document to the end where the Council presents four scenarios on good and bad MFA.  These are well documented and explain the thought process behind why the scenario works or does not work for MFA.  The key takeaway of all of this is the independence of the MFA solution from the logon process.  The Council is getting in front of the curve here and stopping people from creating insecure situations where they believe they are using MFA that minimizes or stops breaches through administrators or users with access to bulk card data.

Now for a few things that I do not necessarily agree with in this document.

The first involves the Council’s continued belief that hardware security modules (HSM) are actually only hardware.  On page four, the following statement is made.

“Hardware cryptographic modules are preferred over software due to their immutability, smaller attack surfaces, and more reliable behavior; as such, they can provide a higher degree of assurance that they can be relied upon to perform their trusted function or functions.”

The Council has made similar statements over the years in the mistaken assumption that HSMs are only hardware.  HSMs are hardware that use software to manage keys.  There are standards that are followed (e.g., FIPS 140) to ensure that the HSM remains secure, but these devices are predominately software driven.  That is not to say that just any device can serve as an HSM, but a lot of us in the security community are concerned that the Council continues to perpetuate a myth that HSMs are only hardware which is patently false.

My other issue comes on page six as part of the discussion regarding the use of SMS for MFA.

“PCI DSS relies on industry standards—such as NIST, ISO, and ANSI—that cover all industries, not just the payments industry. While NIST currently permits the use of SMS, they have advised that out-of-band authentication using SMS or voice has been deprecated and may be removed from future releases of their publication.”

While everything in this statement is accurate, it gives the uninitiated the impression that SMS or voice is no longer a valid MFA solution.  I know this to be true because I have fielded some questions from clients and prospects on this subject, particularly about SMS.  The key is that this is not SSL and early TLS where NIST called them out as insecure and to no longer be used.  This is a “heads up” from NIST to everyone that there is an issue that makes SMS and voice not secure enough for MFA.

But while there is a risk, a lot of us in the security community question the viability of that risk when matched against merchant risk versus a bank or a government agency.  While I would not want any bank or government agency to use SMS or voice for MFA, a small business may not have a choice given their solution.  The reason is that the risk of an attack on SMS or voice is such that only a high-value target such as a bank or government agency would be worth such an effort.  In my very humble opinion, while a total ban is the easy solution, this is an instance where the Council should take a more nuanced approach toward the use of SMS and voice for MFA.  The bottom line to me is that small merchants using any MFA solution, even if flawed, is better than using no MFA solution.

I would recommend the following approach to manage this risk.

  • Level 4 merchants can be allowed to use SMS or voice for MFA.
  • Level 1, 2 and 3 merchants would be allowed to transition away from SMS and voice to a more secure MFA solution within one year of NIST stating that they are no longer acceptable.
  • All service providers would not be allowed to use SMS or voice for MFA once NIST states that both are no longer acceptable. This means service providers should start transitioning now if they use either.

Those are my thoughts on the subject.  I look forward to the comments I am sure to receive.

15
Dec
16

The Council Speaks On A Number Of Topics

The Council had a Webinar session for QSAs and ISAs on Thursday, December 15. It was a great session, but at only an hour, there were a lot of questions that went unanswered.  The following were the more notable discussion topics.

Not Tested

The Council got the message and they are working on new wording for the AOCs as well as some guidance for “Not Tested” and how it can be used and not impact PCI compliance.  They expect to have something issued in the first quarter of 2017.

Network Segmentation and Scoping

This was a very hot topic and drew a lot of questions and some useful answers as well as generating a slew of new questions.

We got a definition of “purpose-built controls”.  There really is not any change here in what the Council has told QSAs and ISAs in the past regarding segmentation.  The bottom line is that “purpose-built controls” are those controls that segment one network from another network.  That can be firewall rules, access control lists (ACL) or any other controls that control or limit the communications from one network to another network.  I posed a question regarding encryption such as TLS and IPSec as still being a valid segmentation control, but it did not get answered.  I am assuming that it still is a valid control given the Council’s statement that nothing has changed, but until we have explicit confirmation, that still is an assumption, not a fact.

The Council answered a number of questions regarding whether or not in-scope devices can be on the same network segment as out of scope devices can co-exist.  As usual, we go the “it depends” discussion.  The bottom line is that it depends on the threat presented by the out of scope devices to those in-scope.  If an organization has lax security controls over all of their networks and devices, then I would be hesitant to allow out of scope devices to be on the same network segment as in-scope devices.

One of the most amazing discussions on this topic was an answer given regarding whether or not a device that has only an outbound connection from the cardholder data environment (CDE) can be considered out of scope.  Under the Open PCI Scoping Toolkit, this would be categorized as a 2C system.  The Council started out with their stock answer of “it depends” and then clarified that answer.  The answer given was that while the system would be in scope because it is connected to the CDE, what requirements it would need to comply with would depend on the risk presented by the system to the CDE.  This seemed to give organizations an opportunity to argue a minimization of requirements.  I am sure this will result in a lot of arguments between QSAs, ISAs and their assessees in the future.

As a funny aside, the Council mentioned the “three hop rule” and then feigned ignorance as to where it came from.  As I pointed out in my post, it was from the 2014 Community Meeting in Orlando.

Not-Listed Encryption Solutions

This guidance is a train wreck and just seems to keep getting worse.  The Council gave a lot of answers to questions, but it just seemed like they were digging an ever deeper hole, not filling it in.

The biggest news is that the Non-Listed Encrypted Solution Assessment (NESA) document should be available for review in the first quarter of 2017.

The next biggest news was the Council reconfirming that this is only guidance/recommendations and not some new process that is mandatory.  They even made sure to tell everyone attending that QSAs are NOT to hold up an organization’s ROC/SAQ over not having a NESA for their E2EE solution.  So if an E2EE solution does not have a NESA, then the fallback based on a lack of guidance from the Council is to preform whatever procedures that the merchant’s acquiring bank recommends.

The purpose of this Information Supplement the Council stated was to provide QSAs, merchants, service providers and banks with the Council’s acceptable way to deal with assessing E2EE solutions.  While on its face this statement and rationale makes sense, it does not make sense from the standpoint that the organizations driving the E2EE solutions are the banks and processors that have partnered with the E2EE solution providers.  Given that the banks and processors are the same organizations driving PCI compliance of the merchants that consume those E2EE solutions it seems rather odd that they would be questioning what is acceptable for PCI compliance of their approved E2EE solutions.

At the end of the day, it just seems that this NESA process is a solution looking for a problem and that the only problem the process really solves is getting more E2EE solutions to just finish the NESA and validate as a P2PE solution.

Until the banks and processors get behind the NESA process, I see this effort as dead on arrival.

So it sounds like it will be a busy first quarter for the Council.

The Council stated that the slide deck for this session will be posted to the Portal sometime after the first of the year.

10
Dec
16

The Council Releases Draft Scope And Network Segmentation Information Supplement

Quietly on Friday, December 9, 2016, the PCI SSC released the draft Information Supplement titled ‘Guidance for PCI DSS Scoping and Network Segmentation’.  As with all Information Supplements, the information documented in these does not replace any of the requirements in the PCI standards.  These documents contain only guidance and suggestions as to how organizations can comply with the PCI standards.

Overall this Information Supplement does not break much new ground regarding the clarifications that have been given over the years on these two subjects.  The Council has taken a much simpler approach to defining categories of systems than did the Open PCI DSS Scoping Toolkit (OPDST).  The Council only has three categories:

  • CDE Systems (Category 1A/B in the OPDST)
  • Connected-to and/or Security-Impacting Systems (Category 2A/B/C/X in the OPDST)
  • Out-of-scope Systems (Category 3 in the OPDST)

One thing the Council has done is provide some good examples for how to prove systems are out of scope.  If a system meets ALL of the following criteria, then it is considered out of scope.

  • System component does NOT store, process, or transmit CHD/SAD.
  • System component is NOT on the same network segment or in the same subnet or VLAN as systems that store, process, or transmit CHD.
  • System component cannot connect to or access any system in the CDE.
  • System component cannot gain access to the CDE nor impact a security control for CDE via an in-scope system.
  • System component does not meet any criteria described for connected-to or security-impacting systems, per above.

The Council goes on further to say that even though these systems are out of scope for PCI compliance, they still need to be secured and patched regularly to ensure the overall security of the organization.

However, there are two points I noted that will likely require some additional clarification from the Council as they are going to potentially cause issues with a lot of organizations.

On page 7, the second paragraph, the document states:

“The existence of separate network segments alone does not automatically create PCI DSS segmentation. Segmentation is achieved via purpose-built controls that specifically create and enforce separation and to prevent compromises originating from the out-of-scope network(s) from reaching CHD.”

The paragraph taken as a whole seems to imply that the Council is taking the conservative position that only firewalls can be considered as network segmentation controls.  It is the phrase “purpose-built controls” that needs to be further defined by the Council.  Earlier in the document there is an example provided using firewalls which the paragraph would definitely lend itself.

In the past, the Council has said that access control lists (ACL) and encrypted tunnels also constituted valid network segmentation.  However this paragraph calls into question whether those are now considered “purpose-built controls” or not.  One would assume so, but as we have all learned in the past, one should never assume with the Council.  As a result, it would be great if the Council could provide clarification on what exactly they mean by “purpose-built controls” in the final release of this document.

The next point of concern is on page 11 in the Connected-to and/or Security-Impacting Systems table.  The third bullet down in the list of criteria states:

“System component can impact configuration or security of the CDE, or how CHD/SAD is handled—for example, a web redirection server or name resolution server.”

It would appear from this statement that the Council has brought Web servers that perform a redirect into scope for PCI compliance as they are considered ‘connected to’ systems.  That will be a huge blow to merchants using redirects to keep their Web servers from having to be ASV scanned and meeting all of the other PCI requirements contained in SAQ A-EP.

The only remaining question is if those Web sites using iFrames will also now be in-scope for SAQ A-EP compliance as well?  Time will tell.

I have no idea when the final version of this document may be released.  But if the Non-Listed Encryption Solutions Information Supplement is any indication, it could be released on this coming Monday to the public.

03
Jul
16

The Council Issues A New Information Supplement

Back in May, the PCI SSC issued a new information supplement titled ‘Effective Daily Log Monitoring’.  It probably slipped under most people’s radar because of the issuing of v3.2 of the PCI DSS.  And for my friend, Anton Chuvakin, this will be on his reading list immediately if he has not read it already because his book, ‘Logging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management’, is listed in the information supplement’s bibliography and from the way this supplement reads, figured prominently in its content.

First some overall impressions.  Unlike a lot of other information supplements, this one actually clarifies and provides a significant amount of knowledge and great advice.  Every organization that needs to meet PCI compliance should read it.  But more importantly, any organization that does not fully understand the collection and analysis of log data should read it to get a foundation in these practices.

One of the best recommendations comes in section 5.2 in the supplement which instructs organizations to develop a baseline from log data.  This is the biggest problem when an organization gets serious about analyzing log data, they fail to baseline the exceptions.  I cannot tell you the number of times that I have discussed logging with the personnel responsible for monitoring for alerts and they cannot tell you what is “normal” activity versus “abnormal” activity.  As a result, they either: (1) chase every alert as though they are an attack (they are not), or (2) ignore alerts because they assume they are “normal” activity (they are not).  The result in case #1 is that they cause burn out in the organization and, of course, in case #2 the organization is likely getting attacked and compromised.

I cannot understate the importance of this activity both in getting a log monitoring project going but also as something that needs to also be an ongoing activity.  No organization’s IT environment is static, so it is important to continuously baseline the log data and adjust for changes.  This can be done by adding an item on change control tickets to evaluate the impact on log data or re-baselining every quarter.  The bottom line is that baselining is not something done once, the baseline must be periodically updated.

The most glaring omission in this document is a reference on page 27 to Appendix B that promises to provide readers with a list of “sample tools” for normalizing log data.  But guess what?  There is no Appendix B.  Hopefully the Council will issue a revision to this document and add Appendix B to that future revision.

If I had to ding this information supplement for anything it is the downplaying of the need to have one or more tools to collect and analyze the log data.  The Council obviously has to walk a fine line on this, but let us be honest.  Anyone that believes that log monitoring and analysis can be done without one or more commercial tools is kidding themselves.  Yes, a person can put up a centralized log collection server and the parse that collection of data with tools such as Grep, Perl or Python.  Again, let us be honest, no one has the time to write all of the necessary scripts or search patterns to find all of the conditions you need to find.

It used to be that there were open source tools such as Splunk and similar available for log gathering and analysis.  However, those days disappeared a number of years back and only commercial versions are available.  So everyone needs to be prepared to spend a certain amount of money to get a toolset that will provide the information gathering and analysis toolsets necessary.

I also fault this document for focusing too much on log information normalization.  This is exactly why organizations need to invest in a commercial tool.  This was the big complaint with using open source tools.  People found that they got basic functionality, but then had to essentially conduct a full-fledged system development effort to get the analysis and alerting done.  This was the big selling point with commercial tools such as LogRythms and ArcSight that came the basics as well as a whole host of analysis templates both free and for purchase.

Another ding I have is the minimal number of requirements that the information supplement identifies as being satisfied by log monitoring and alerting.  I can find at least 15 instances where requirements can be met by monitoring and alerting, not just the eight that are identified in the supplement.

Even with these concerns and shortcomings, this is possibly one of the better information supplements issued by the Council and is a must read by everyone.

To get your own copy of the information supplement, go to the PCI SSC Document Library, select ‘Guidance Documents’ and scroll down to the ‘Logging’ banner.




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

September 2017
M T W T F S S
« Aug    
 123
45678910
11121314151617
18192021222324
252627282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,868 other followers