Archive for the 'Requirement 4 – Encrypt transmission of cardholder data' Category

27
Jan
18

Pre-Authorization And Post-Authorization (Part 1)

Welcome to a new year.  I have had a number of interactions with a variety of people over the previous year and it has become obvious that the concepts of pre-authorization and post-authorization data is not clear to a lot of people.  These two concepts are a key part of understanding PCI compliance.  I will start with pre-authorization in this post and have a separate post for a discussion of post-authorization.

Pre-Authorization

Where pre-authorization (aka “pre-auth”) typically comes up is when someone asks, “How does [pick your online merchant] store a customer’s payment data and still be PCI compliant?”

Before we get to that question, we need to define what we mean by “pre-authorization”.  Pre-authorization is that time when a merchant has a customer’s sensitive authentication data (SAD) or cardholder data (CHD) but has not yet processed it for payment.

For most merchants, that time between collecting the SAD/CHD and processing it is measured in seconds.  For card present (CP) transactions, the SAD can be in the form of chip or magnetic stripe data.  For card not present (CNP) transactions, it typically includes the cardholder name, primary account number (PAN), expiration data and CVV/CVC/CID.  Regardless of transaction type, the data is sent off to either be approved or declined in seconds.

However, there are situations where that does not always happen that quickly.  Mail order telephone order (MOTO) and facsimile orders are the most obvious examples that can extend the amount of time between receipt of the CHD and processing by minutes, hours or even days and weeks.

But there are some not necessarily obvious situations where processing delays occur.

My first example of delay is when you go to fill your car with fuel.  When you swipe your card to pump the fuel, the system that manages the payment process will pre-authorize the purchase and then temporarily store the SAD until you finish pumping and hang up the hose to complete the transaction.  When you complete the transaction at the pump, the system sends through the actual charge and securely deletes your SAD from the system.  Depending on the size of your vehicle’s fuel tank and how close to empty you were, the system could have your SAD for quite a few minutes.

Another example is for the hospitality industry.  In the hospitality industry, a reservation typically does not cause a charge until a customer checks out even though they are required to have a card on file to hold the reservation.  When a customer checks into the property, the hotel’s billing system records the SAD and may also pre-authorize charges, but the actual card transaction is not processed until the customer checks out.  As a result, hotels can have SAD on file for the length of a traveler’s stay.  In fact, I have encountered SAD in hospitality systems that have been stored for more than a year due to reservations for special occasions such as graduations, birthdays, family reunions and anniversaries.

But getting back to the original question, the example that usually draws the most questions is in regards to when you, as a customer, store your card information with a merchant for future purchases.  These entities store your payment information (pre-authorization) in their applications so that you or they can quickly pay for your purchases without constantly re-entering your payment information.  These applications are not always part of a payment application, so they may or may not be PA-DSS validated.  However, when encountering them, I use the PA-DSS standard to ensure they process, store and transmit the SAD/CHD securely.  In addition, as a customer, you should have explicitly approved of the merchant storing your payment data and know how they will use that data.

Last, but not least, another great example of pre-authorization data are eWallet applications such as Google Pay and Apple Pay.  eWallets are just an electronic version of a consumer’s physical wallet.  eWallets are not regulated by the PCI standards or the card brands nor are they required to be PA-DSS validated.  Not that these eWallet applications are not secure, it is just that there is no one independently validating that they are secure.  That said, I always instruct developers of eWallet applications (or any pre-authorization applications) to follow the PA-DSS for developing a secure eWallet application.

The most confusion I encounter over pre-authorization data typically occurs regarding SAD/CHD that an organization receives via email or instant messaging.  A lot of QSAs get their undies in a bunch over when this happens and point to requirement 4.2 as the reason why this is unacceptable.  As a refresher, requirement 4.2 states:

“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”

The operative word in 4.2 is “send”.  Requirement 4.2 says nothing about receiving PANs by these methods.  That does not mean that the Council recommends receiving PANs via email, IM or similar methods.  It is only recognition of what goes on in the real world.  There will always be a small percentage of people that will send their cardholder data insecurely and there is little an organization can do to stop it.

Yes, you can put a data loss prevention (DLP) solution in the middle of all of these messaging technologies and catch the bulk of the offenders.  But then what?

I have some clients who have taken this approach and the DLP securely deletes the message and triggers a message back to the sender stating that they do not accept payment card information via this communication channel and then explains all of the appropriate and approved ways a customer can communicate SAD/CHD.

I have other clients that use the DLP but do not delete the message.  They explain that in this one instance, they will process the transaction because they are all about the customer experience.  They have a process that they follow to handle the message and then securely delete it.

To keep your email, IM and other messaging systems out of scope, the Council has told QSAs that organizations must have a policy in place that says they never encourage customers to use these messaging channels for communicating SAD/CHD and to make sure that organizations have a process to remove the SAD/CHD as soon as possible from those systems.  That typically involves the printing of the message, deleting the message from the system(s) and then securely destroying the printed message once the transaction is processed.  This is all considered “incidental contact” in the eyes of the Council and the QSA can then consider the system out of scope as long as they can satisfy themselves that the manual process is reliable.

The bottom line is that all of these situations involve pre-authorization data and pre-authorization data can include everything recorded on a card’s track or chip.  If a merchant does store the pre-authorization data for the convenience of their customers, they are obligated under the PCI DSS to store it separately, away from post-authorization data and to protect it with the same rigor as post-authorization data, i.e., encrypted, extremely limited access, logging, monitoring, etc. 

That is a key point that is often missed.  Pre-authorization data must be stored separately and away from any storage of post-authorization data.  That means that separate instances of databases need to be used on separate servers.  The rationale for this is no different than keeping key encrypting keys (KEK) away from data encrypting keys (DEK).  It is to ensure that in the event of a breach of post-authorization data, it does not readily lead to a breach of pre-authorization data.  It also allows for more rigorous controls over the pre-authorization data.

One final point regarding pre-authorization data that I made earlier, but it needs to be reiterated.  If a merchant intends to store pre-authorization data, I highly recommend that you have a legal agreement in place between your organization and your customers that explains why your organization is retaining this information and the business purpose(s) for which the information will be used.  That can be similar to a license agreement that the user either signs or clicks “Okay” online to acknowledge their approval.

In a future post I will discuss the world of post-authorization where the PCI standards were originally focused.

Advertisements
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.

09
Apr
16

Living In PCI Denial

This was one of those weeks where you see something and all you can do is shake your head and wonder what some organizations think when it comes to PCI.  What added insult to injury in this case was that the organization arguing over PCI compliance is the manufacturer of card terminals, also known as point of interaction (POI).  It shocked me that such an organization was so clueless about PCI as a whole when you would think it is their business to know. But to add insult to injury, my client’s transaction processor and acquiring bank are also apparently clueless.

As background, I am working on a client’s Report On Compliance (ROC).  This client has almost completed with their roll out of an end-to-end encryption (E2EE) solution at all of their 4,000+ retail locations.  This E2EE solution will take all but the POI at those retail locations out of scope for PCI compliance.  That is the good news.

But if there is good news, you know there must be bad news.  In reviewing their documentation of this E2EE solution, I discovered that the POI vendor is providing management and updates to the POI through a terminal management system (TMS).  Since this TMS solution/service connects directly to my client’s cardholder data environment (CDE), I naturally asked the client for a copy of the vendor’s Attestation Of Compliance (AOC) for the TMS solution/service.

I thought those worthless PCI Certificates of Compliance took the cake.  Then, BAM!  I got the following message forwarded to me by my client from the POI vendor.  I have redacted all of the potential information that could identify the relevant parties and the TMS solution/service.

“Please see the follow up note below that you can send to your QSA for review and feedback:

  1. TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk. Since [vendor solution] does not have any card holder data at all, it falls outside of PCI requirements.  [Vendor solution] is merchant configuration and estate management tool only and as such, no payment card information passes through it, or directed to it.  In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.
  2. [Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website. Transactions are encrypted in hardware using the [encryption solution] keys which again [vendor solution] has no knowledge.  Transaction information can only be decrypted by [processor] the processor.  [Vendor solution] has no knowledge of this encrypted information being sent directly from the [vendor] to the processor.
  3. The beauty and simplicity of [vendor solution] semi-integrated terminal application is that is has all transaction data go directly to the Processor ([processor]) and no customer data is directed to the POS or [vendor solution] which makes the POS out of PCI Scope by the very nature of no card holder data in their environment.
  4. [Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application. Any questions regarding the certification should be directed to [acquiring bank] or a [processor] representative.

Let us know if your QSA has any further questions and we can also schedule a concall with all parties to address any concerns on [vendor solution] TMS and PCI.”

The first thing that wound me up is that this vendor is a business partner of my client’s transaction processor.  The processor is also a business partner of my client’s acquiring bank.  Those two organizations put forth this vendor to my client as being able to provide POI compatible to the processor’s E2EE and tokenization solution.  Obviously from this vendor’s response, these two well-known institutions did nothing in the way of due diligence to ensure that this vendor and its services were PCI compliant.

The second thing that totally irritated me is that there is no excuse for this vendor’s uneducated response.  Granted, this vendor is new to the US market, but they have been supplying POI to other merchants all over other parts of the world.  Which then starts to make you wonder just how lame are the banks, processors, card brands and other QSAs that they have not been called on the carpet about this before.  But that is a topic for another post and a good reason why the FTC is investigating the PCI compliance industry.

So let me take apart this vendor’s response.

“TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk.”

Wrong!  On page 10 of the PCI DSS the first paragraph under ‘Scope of PCI DSS Requirements’ clearly defines what is in scope for PCI compliance.

“The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.”

The operative phrase the TMS solution/service falls under is “connected to”.  The TMS solution/service directly connects to my client’s CDE.  That solution/service may not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD), but it is directly connected to my client’s CDE.  As a result, according to the above definition, the TMS solution/service is definitely in scope for PCI compliance.

“[Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website.”

PTS certification is a card brand requirement, not a PCI DSS requirement.  Nowhere in the PCI DSS does it require that a PTS certified POI be used so I really do not care about this statement as it has nothing to do with my PCI DSS assessment activities.  If PTS were a PCI DSS requirement, then all of those people using Square and the like would be non-compliant.

“In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.”

“Transaction information can only be decrypted by [processor] the processor.”

True, your TMS solution/service does not have the encryption keys.  But the firmware delivered by the TMS solution/service does have access.  (Unless you are the first POI vendor I have ever encountered that spent the huge amount of money required to truly create a hardware-only encryption solution.)  Given the low retail price and discounting of your POI you gave my client, I very seriously doubt that is the case.  So the firmware that your TMS solution/service delivers is what is doing the encryption and therefore has access to the encryption keys.  So while the TMS solution/service does not have the keys, it could be used to deliver rogue firmware that could obtain them.

Then there is the firmware delivery itself by your TMS solution.  If someone hacks your TMS environment, how easy would it be for them to have it deliver a rogue version of your firmware?  Since my client has no AOC, I have no idea if your security measures surrounding your TMS solution are adequate to prevent such an attack.

“[Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application.”

Such a statement ranks up there with those previously mentioned worthless PCI Certificates of Compliance.  Any QSA is required to obtain an AOC for the TMS solution/service to ensure that it is PCI compliant or the solution/service must be assessed as part of the merchant’s PCI assessment.

PCI DSS requirements under 12.8 are very clear as to everything a merchant needs to be able to provide to their QSA regarding third party PCI compliance.  Primarily of which is that AOC for your TMS solution/service among other items of evidence.

So I have a conference call with my client’s bank to discuss this situation.  I pushed back very hard when they told me that my client needs to do a compensating control for their business partner’s incompetence.  I even got an “atta boy” from the bank for identifying to them that they have a PCI compliance and potential security issue.  But I could not make the bank budge on the compensating control so I am off to get that written.

The lesson to be learned from this post is that nothing can be taken for granted when doing a PCI assessment even when you transaction processor and bank are involved.  A lot of people and QSAs would assume that a POI vendor would know better and that their bank and transaction processor had vetted the POI vendor.  Therefore, why do I have to worry about this vendor?  However as I have pointed out, you can never take anything for granted even when it involves organizations that you would think would know better.

This is just one way of many that could result in an organization being breached.  The TMS solution/service is a gateway directly to the merchant’s CDE.  Yet there has been no PCI assessment of that solution/service to ensure that it is PCI compliant and the risk it could be subverted has been minimized.

Thank goodness it is the weekend.  Oh, wait.  This weekend’s project is my income taxes.  Looks like I will be cranky all weekend as well.

07
Apr
16

Just Because You Can Wait, Does Not Mean You Will Be Judged “Compliant”

Based on some of the questions I have received since my post on v3.2, apparently a lot of people missed this little point in my last post about the Council’s Webinar.

“The final key point on this topic that the Council could not stress enough was, just because the deadline has been pushed out was no justification for an organization to wait until the last minute before addressing these critical vulnerabilities.  If an organization can meet the June 30, 2016 deadline, then they should meet that deadline.  If they need until December 31, 2016 to convert, then they need to mitigate the risk until December 31, 2016 when they can drop SSL and early TLS.  But waiting for the sake of waiting because the deadline is in 2018 is unacceptable and needs to be called out as ‘Not In Place’ by QSAs.”

For all of you in denial out there, make sure you truly read that last sentence.

Yes folks.  Your QSA can mark you as non-compliant if your organization does not have a very, very, very good and legitimate documented business reason for not meeting the June 30, 2016 deadline for getting rid of SSL and early TLS.

Want to argue that point?  Fine.  Then you can expect your QSA to put you in arbitration with your acquiring bank on this subject.  If your acquiring bank is willing to sign off on your lame delay, then so be it.  But if your bank denies your request, then expect to be put into remediation by your bank and possibly even be fined for your arrogance.

And one more thing we have since clarified.  If you can meet the June 30, 2016 deadline, then you only need mitigation and migration plans for your QSA.  If you are not going to meet the 2016 deadline, then in addition to the plans your organization will also need to provide a compensating control worksheet (CCW) for 4.1.  Even if you are filing your Report On Compliance (ROC) before June 30, 2016, you still need to provide your QSA with the plans and the CCW if you will miss the 2016 deadline.

So for all of you out there that thought you had dodged a bullet, there is another bullet with your name on it.  You have been warned.

18
Dec
15

This Just In – SSL Conversion Deadline Has Changed

This is hot off the presses from the PCI SSC.

I’m not sure I necessarily like this decision, but I can appreciate what is driving it.  That said, I think the better approach would have been to have organizations do compensating controls for keeping SSL around.

Read the update for yourself.

http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls

14
Nov
15

Small And Mid-Sized Businesses

At this year’s PCI Community Meeting, the push was to address the security issues faced by small and mid-sized businesses, otherwise referred to as SMB. However, in my opinion, the approaches being suggested are still too complex. Great security results from simplicity, not complexity. As a result, I propose the following approach for SMBs because SMB executives typically have little time to fully educate themselves in information security, let alone, PCI. And while I am of the opinion that executives should have such knowledge, it is just not happening.

There Are No “Silver Bullet” Solutions

First and foremost. There are no “silver bullet” solutions that will entirely remove your organization from PCI scope. Any vendor telling you that their solution removes your organization from PCI scope is lying to you. If you hear such a statement from a vendor, the vendor does not know what they are talking about and their statements regarding PCI should no longer be trusted. The bottom line is that, if your organization accepts credit/debit cards for payment for goods/services, the organization will always have some PCI scope. The least amount of scope an organization can achieve is complying with the requirements listed in the SAQ A. There is nothing less. Anyone telling you otherwise does not know what they are talking about.

DO NOT STORE CARDHOLDER DATA (CHD)

This is probably the biggest single thing an SMB can do. In this day and age, there is no reason that any organization needs to retain CHD. Period. The most common business justification is that the organization does recurring transactions and that is the reason to retain CHD. Processors have a solution for that situation and many others. So I say it again. There is no valid business reason for any organization to retain CHD. None. Nada. Zip.

The first question out of an SMB executive’s mouth to a payment solution vendor should be, “Does your solution store cardholder or sensitive authentication data?” If the answer is anything other than an immediate and definitive “NO”, the meeting or telephone call is over, done, complete. There is nothing more to discuss. SMBs must stop being an easy target for attacks. The easiest way to do that is not having the CHD in the first place.

The second question that a payment vendor should be asked is, “How does your solution minimize my organization’s PCI scope?” If the vendor cannot provide you with a whitepaper on this subject, run away. If the documentation provided by the vendor leaves you with more questions than answers for PCI compliance, you also need to run away. In all likelihood, if this is what you encounter, the vendor’s PCI compliance is questionable, complex or requires too much effort on your part to be PCI compliant. This question should result in a one to three page whitepaper on PCI and how the vendor’s solution minimizes your organization’s scope.

So what solutions reduce scope to the minimum?

If you are a traditional brick and mortar retailer, end-to-end encryption (E2EE) from the card terminal, also known as the point of interaction (POI), to the transaction processor. PCI has a validation program called point-to-point encryption (P2PE). P2PE solutions are independently validated to ensure that they are secure. Solutions such as Shift4’s Dollars on the Net, First Data’s TransArmor and Verifone’s VeriShield are E2EE solutions that could meet the P2PE standard, but for various reasons the providers chose not to validate them to the P2PE standard. The key capability for any such solution is that the solution encrypts the CHD/SAD immediately when it is read from the card and none of your organization’s technology can decrypt the information and therefore read it.

If your organization does eCommerce, then you want to use a redirect or iFrame to process transactions in order to reduce PCI scope. The best example of a redirect is when a merchant uses PayPal for processing payments. The merchant’s Web site has a PayPal button that sends the customer to PayPal who then processes the customer’s payment transaction. At no time does the sensitive authentication data (SAD) encounter the merchant’s Web site. One of the concerns from merchants about redirects is the myth that customers vacate their shopping carts because they are redirected to a different site for payment. While this was true in the early days of eCommerce, with the increased use of PayPal and similar payment services, customers seem to have gotten over that practice and vacated shopping carts are no longer an issue. But if this is still a concern, use this as a teaching moment and educate your customer base that you do the redirect to ensure the security of their SAD.

An iFrame is essentially a Web page within a Web page. But the key thing from a PCI compliance perspective is that the iFrame is produced and managed by a third party, not the merchant. An iFrame can be a Web page, but more often than not it is a series of fields that gather the SAD for conducting a payment transaction. As with the redirect, the SAD never comes into contact with the merchant’s Web site.

Both of these solutions take your organization’s Web site out of scope so you do not need external and internal vulnerability scans and penetration tests. However, just because your Web site does not have to go through the rigors of PCI compliance, you still need to ensure its security. See my post on SAQ A and SAQ A-EP for a more detailed discussion on this topic.

Tokenization

Tokenization is the act of encrypting or tokenizing the primary account number (PAN) so that when it is returned to the merchant for storage it has no value to anyone if it is disclosed. Tokenization can occur at the time a card is swiped or dipped at the terminal or it can be done by the transaction processor at the back end of the transaction. Regardless of where the tokenization occurs, paired with E2EE or P2PE, tokenization further minimizes PCI scope.

If your organization needs to perform recurring transactions such as with subscriptions or automatic reorders, tokens can be generated by the processor so that they can be used just like a PAN. While a token is not a PAN, in situations where they can be reused for future transactions, it is incumbent upon the merchant to protect access to the token so that it cannot be sent to the processor for fraudulent charges.

And that is it. Not storing CHD, E2EE/P2PE and tokenization will reduce an organization’s PCI compliance footprint to the absolute minimum. It really is that simple. However, finding the solutions that bring all of that to the table is where the work comes in. However, any SMB that asks the right questions of its vendors can put together a solution that minimizes their scope and provides protection for CHD/SAD as good as with the big boys.

31
Oct
15

SSL Is Not Going To Go Quietly

A lot of organizations are finding out that just turning off SSL is just not an option. This is particularly true of merchants running eCommerce sites predominantly used by mobile customers or customers running older operating systems. To the surprise of a lot of IT people, it turns out that most mobile browsers do not support using TLS. And while most Western PC users have reasonably current browser software, the rest of the world does not and turning off SSL will remove a significant portion of some merchant’s customer base. As a result, for some organizations going “cold turkey” on SSL is just not an option without suffering significant consequences.

But there is a larger problem with SSL lurking inside almost every data center. That is with appliances and data center management software that have SSL baked into them for their Web-based management interfaces. A lot of vendors availed themselves of OpenSSL and other open source SSL solutions to secure communications with their appliances and solutions. To remediate these solutions, an organization might be lucky enough to upgrade the firmware/software. Unfortunately, a lot of organizations are finding that replacement is the only option offered by vendors to address these situations.

The bottom line is that because of these situations, SSL and early TLS will not be addressed by just disabling it and moving on. As the PCI SSC found out when they asked Qualified Security Assessor Companies and Participating Organizations about what it would take to address the SSL/early TLS situation, they were told about these issues and therefore set a deadline of June 30, 2016 to provide time to address these situations.

While organizations have until June 30, 2016 to address SSL and early TLS, that does not mean an organization can just sit by and do nothing until that deadline. Here are some things your organization should be doing to address SSL and early TLS if you are unable to just turn it off.

  • Get a copy of NIST Special Publication 800-52 Revision 1 titled ‘Guidelines for the Selection, Configuration and Use of Transport Layer Security (TLS) Implementations’. This publication is the Bible for how to minimize and mitigate the risks of SSL and early TLS.
  • Identify all instances of where SSL or TLS are used and versions supported. It is not just those instances that need to be remediated, but all instances. The reason is that TLS v1.3 is in draft specification and its release is likely just around the corner in 2016. That is why a complete inventory is needed so that when TLS v1.3 is available you will know what remaining instances will potentially need to be updated, upgraded or possibly even replaced.
  • Implement TLS-FALLBACK-SCSV to minimize the chance of SSL/TLS fallback. This option was developed to address the issue created by POODLE. However, be aware that only certain versions of browsers support this option, so it is not a perfect solution.
  • Monitor your external Web sites for SSL and early TLS usage. Track statistics of how many sessions are using SSL or early TLS so that you can determine usage of those protocols and therefore know the actual impact of any decision regarding those protocols. These statistics will also allow you to know when you might be able to pull the plug on SSL and early TLS with minimal impact.
  • Modify any external Web sites to present a message to anyone using SSL or early TLS to warn them that you will be no longer supporting SSL/early TLS as of whatever date your organization chooses to drop that support.
  • Where possible, configure the Web site to only use SSL or early TLS as the absolute last resort. Unfortunately, a lot of vendors modified their SSL solution to not allow this sort of change so do not be surprised if that does not become an option.
  • Develop a migration plan for your remaining instances where SSL or early TLS are used. Contact vendors involved and document what their plans are for dropping SSL and early TLS.
  • Be prepared to create compensating controls for SSL and early TLS that you will not be able to remediate by the deadline. Unfortunately, I have a sneaking suspicion that some vendors will miss the June 30, 2016 deadline as will some merchants be unable to turn off SSL by the deadline. As a result, those organizations will have to put compensating controls in place to maintain PCI compliance. These compensating controls will likely be messy and complex as enhanced monitoring will likely be the only controls available.



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

May 2018
M T W T F S S
« Apr    
 123456
78910111213
14151617181920
21222324252627
28293031  

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

Join 1,964 other followers

Advertisements