Posts Tagged ‘PA-DSS

18
Feb
15

Council Surveys QSAs On SSL

This message popped into my inbox late yesterday.

20150217-PCISSCemailMsg

The survey in question contains the following questions.

20150217-PCISSCSurvey

All of my clients have gotten rid of SSL on their public facing Web sites.

The dilemma we have is that while SSL is dead, it is baked into so many products and appliances.  My clients are therefore stuck with appliances and software products that have SSL hard coded into them.  As a result, they will be dependent on their vendors to convert to TLS.

That said, what is the risk of using SSL internally?  Not a good practice, but truthfully, what is the risk?

In my opinion, using SSL internally for the next 12 to 24 months would not be the end of the world as long as it does not become a significant attack vector.

It will be interesting to hear the results of this survey.

Advertisements
07
Feb
15

SSL Is Officially Declared Dead

On January 30, 2015, QSAs received the latest edition of the Council’s Assessor Newsletter.  Buried in that edition was the following statement.

Notice: PCI DSS and PA-DSS v3.1 Revisions Coming

In order to address a few minor updates and clarifications and one impacting change, there will be a revision for PCI DSS and PA-DSS v3.0 in the very near future. The impacting change is related to several vulnerabilities in the SSL protocol. Because of this, no version of SSL meets PCI SSC’s definition of “strong cryptography,” and updates to the standards are needed to address this issue. (Highlighting emphasis added by the PCI Guru)

We are working with industry stakeholders to determine the impact and the best way to address the issue. While we do not have the final publication date, our goal is to keep you apprised of the progress and to provide you with advanced notification for these pending changes. We are also preparing several FAQs that will accompany release of the revised standards.

Should you have any questions, please contact your Program Manager.”

Because the announcement was titled about the coming v3.1 revisions to the PCI DSS and PA-DSS standards, I am sure a lot of QSAs missed this pronouncement.

Not that this should be a surprise to any QSA as the POODLE vulnerability effectively killed SSL.  The Council has now officially announced that SSL is no longer deemed to be strong cryptography.

Therefore, those of you still using SSL to secure transmissions containing cardholder data (CHD) need to stop that practice as soon as possible and convert to TLS or IPSec.

UPDATE: On February 13, 2015, the PCI SSC issued an update to their original announcement in the Assessor Newsletter.

24
Jul
14

Keeping It Simple – Part 2

In Part 1, the key to keeping things as simple as possible is to avoid any storage of cardholder data.  Period.  End of discussion.

I also covered mobile payments because more and more small merchants go to those solutions because of the cheap interchange fees on transactions.  However, few small merchants truly understand the risks that these solutions present because they are offered by seemingly trustworthy providers.

So what else can you do to keep things simple?

Outsource

When consultants typically mention outsourcing, huge amounts of money typically float past people’s eyes.  However, PayPal is outsourcing and its fees are not too bad.  There are a number of similar services for eCommerce out there for conducting payments.  There used to be concerns about abandoned shopping carts because of a separate Window pop up, but as online shoppers have gotten used to PayPal like services, that has diminished.

Your bank may also have a partnership with one or more payment vendors, so it is worth it to talk to them first to find out what options they may have to offer.  If they do partner with a payment solution, a lot of times they can offer reduced fees/expenses and other incentives to use their partner(s).

The key thing to understand is that even when you invoke PayPal or similar services from your Web site, you still have a responsibility to ensure the security of your Web site.  This is because your Web site is the system that directs your customer to the payment service you have chosen.  If an attacker changes that redirect to “The Guru’s Payment Process”, that is not PayPal’s problem, that is your problem.  This was clarified in the PCI SSC’s Information Supplement on eCommerce back in January 2013 when the Council declared that even Web sites that redirected to a payment service still were in scope, albeit a very reduced scope.  The ramifications of this supplement have been discussed repeatedly with QSAs since then, but in my experience that message is still not being consistently presented to QSAs’ customers.

No Choice But To Store Cardholder Data

So you have found a solution that does exactly what your business needs, but it stores cardholder data (CHD).  The first question you should ask the vendor is, “How does your solution secure the stored cardholder data?”

For vendors that use data encryption, the answer to this question should be either triple DES (3DES) 168-bit or advanced encryption standard (AES) 128-, 192- or 256-bit encryption.  DES and 3DES 56- and 112-bit are no longer considered secure, so any vendor using those is not meeting the PCI encryption requirements.  Anything else and you should consult with a QSA as to whether or not the encryption algorithm is acceptable.

For vendors using encryption, the next question you should ask them is, “How does your solution perform key management?”  Preferably, someone other than someone in your organization manages the encryption keys such as the vendor.  However, I have seen some solutions where the key management is done by the merchant through a sophisticated key generation solution in the application so that the merchant never actually knows or has access to the encryption key(s).  The questions you need answered are all in requirements 3.5 and 3.6 of the PCI DSS.  If the vendor cannot address these requirements, then you need to find a new solution vendor that can provide answers.

For vendors that use one-way hashing, the preferred algorithms used should be SHA-2 or SHA-3 with a salt value.  MD5 and SHA-0 have known security issues that make them no longer secure.  SHA-1 has a potential security issue that could cause data to also be insecure, but a lot of software vendors still use SHA-1 with a salt value.  If you are going to use a solution that relies on SHA-1, the vendor should have additional controls in place to monitor access to the data and alert on any access where the data is being accessed in bulk.  If not, find another vendor.

Tokenization

Do not give up hope if your preferred solution stores cardholder data (CHD).  You may be able to use a processor that tokenizes the PAN.  Once tokenized, the PAN is no longer considered CHD, so the solution would not being storing CHD.

Proper tokenization is a form of encryption or hashing in that the token does not have any true one-to-one relationship with the PAN it replaces.  However, this is a fact you need to confirm with the transaction processor to ensure that their tokenization process is secure.  If they are not representing their token as secure, you need to move on to another processor.

Tokenization can occur at the swipe/dip of the card at the point of interaction (POI) or as the byproduct of the successful completion of a transaction (the most common occurrence).

Tokens can also be generated for eWallet situations where you want to encourage customers to come back and shop at your eCommerce site and store their cardholder information for ease of subsequent transactions.  In these instances, the processor generating the token also stores the CHD and then translates the token to that stored CHD when your system submits it and then sends the CHD for approval for payment.

This is how ExxonMobil Speedpass and open road toll collection systems work.  The RFID device is the token and the payment system recognizes the serial number of the RFID device and translates that to the customer’s stored CHD for payment processing.

There are more than enough ideas presented in these two posts to vastly simplify any merchant’s PCI compliance exposure.  If these solutions will not solve your issues, then you are either making your business too complex or your business model truly needs some expert advice to address your compliance challenges.

08
Feb
14

Pre-Authorization Data

After a number of interactions with a variety of people over the last few weeks, it has become obvious that the concept of pre-authorization data is not clear to a lot of people.  And just because it is pre-authorization data does not mean that you are not required to protect it.  The Council has made it very clear that it is to be protected with the same rigor as post-authorization data.

Pre-authorization is defined as that time when an organization has a customer’s sensitive authentication data (SAD) but has not yet processed it for payment.  For most merchants, the time between collecting the SAD and processing it is measured in seconds.  For card present transactions, the SAD can be track or chip data.  For card not present transactions, it typically includes the cardholder name, primary account number (PAN), expiration date and CVV2/CVC2/CID2.

Here are some situations where that does not always happen that quickly.

Phone, facsimile and mail orders can extend the amount of time between receipt of the SAD and processing by seconds, minutes or even hours.  On the bizarre side of things, I encountered at one client people sending their physical cards in the mail for processing of their mail order.

At the fuel pump when a customer swipes their card, the system that manages the payment process will pre-authorize the purchase and then store the SAD until the customer finishes pumping fuel and hangs up the hose to complete the transaction.  That could be five to 10 minutes depending on fuel tank size.

In some industries the time of pre-authorization can be weeks, months and in some cases even a year or more.  Where this typically occurs is in the airline and hospitality industries.

When a customer makes an airline reservation, the airline will likely pre-authorize your airfare but may not actually charge your card until 7/14/60/90 days before you check in or even until you check in.  This can result in your SAD being stored for weeks or even months.

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.  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.  New versions of hospitality management systems encrypt pre-authorization data, however older systems did not and the security of the pre-authorization data may not be a rigorous as it should.

eWallet applications are another great example of pre-authorization data.  eWallets are just an electronic version of a consumer’s physical wallet.  eWallets can be applications on a smartphone/tablet or a specialized device such as Coin.  eWallets are not regulated by the Council or the card brands and never will be just as traditional wallets are not regulated.  That said, developers of eWallet applications should follow the PA-DSS for developing secure eWallet applications.

The most confusion over pre-authorization data typically occurs over SAD that an organization receives via email.  A lot of QSAs get their “undies in a bunch” over this and point to requirement 4.2 as the reason why this is unacceptable.  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 and the reason is that it is pre-authorization data.  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.  But even before you start the argument, you need to acknowledge that this data is pre-authorization data because a transaction has yet to be processed.

To keep your email system out of scope, the Council has told QSAs to make sure that organizations have a process to remove the SAD as soon as possible from the system(s) in question.  That typically involves the printing of the message, deleting the message from the system 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 and consistently executed.

Web sites that store customers’ SAD for future purchases are also dealing in pre-authorization data.  Merchants providing such a service should contractually acknowledge their responsibility to protect that data with the same rigor as post-authorization data and that the stored data is only for use for purchases by the customer on the merchant’s Web site.

My final example of pre-authorization data is when an organization’s travel department stores employees’ card data for company travel reservations.  The systems used by these departments typically store the cardholder name, PAN, expiration date and the CVV2/CVC2/CID2.  When the PCI DSS originally was published, the card brands instructed QSAs that these sorts of systems were not in scope for an organization’s Report On Compliance (ROC).  However, as time has passed, some of the card brands now want those systems included in the ROC, so organizations need to contact the card brands to determine if their ROC should include such systems.  These systems can be interesting in how little protection they can provide for SAD, so regardless of whether they are included in the organization’s assessment, the organization should review the security of the application against the PCI DSS and mitigate any gaps.  As with the aforementioned Web sites that store pre-authorization data, an organization storing SAD for their employees should legally acknowledge their responsibility to protect that data as well as document how it may be used.

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 magnetic stripe or chip.  Merchants can store pre-authorization data until a payment transaction is processed.  If they do store the pre-authorization data, they are obligated under the PCI DSS to protect it with the same rigor as post-authorization data, i.e., encrypted, extremely limited access, logging, monitoring, etc.

Hopefully we are now all on the same page.

02
Dec
13

PCI DSS v3 and PA-DSS v3 – Wait For It

There are all sorts of QSAs and other experts who are weighing in on the new versions of the PCI DSS and PA-DSS that were released around the first part of November.  In my very humble opinion, all of this discussion is speculation, at best, because the PCI SSC has not released the final pieces of the standards puzzles.  Those final pieces are the respective Reporting Templates for those standards.  Without those templates, QSAs and PA-QSAs have no idea of what the true testing and reporting requirements they will be held.  As a result, the impact of the changes to the standards will not truly be known until QSAs and PA-QSAs have the templates and can review the new testing and evidence requirements.  While I am not expecting the sort of major changes that resulted when the version 2 Report Instructions were released, there still could be some surprises that could impact the amount of work and evidence collected.  The PCI SSC has not committed officially to a release date for the Reporting Templates, but the rumor is that they will be available around the first part of March 2014.

There are some comments that can be made and I will be covering some of those points on a Webinar sponsored by Tripwire on Monday, December 16, at 7PM UTC / 1PM CST.  If you care to attend, you can register for the session here.  “See” you there.

07
Nov
13

Hot Off The Press

The PCI SSC released the final versions of the PCI DSS v3 and PA-DSS v3 this morning.  You can get your copies here as long as you sign their agreement.  The Change Summary documents for both are also finalized and available in the library.  Enjoy!

06
Oct
13

Thoughts From The 2013 PCI Community Meeting

I got lucky that my new employer allowed me to go to this year’s PCI Community Meeting held in Las Vegas.  It is always nice to hear things first hand versus getting the slide decks, asking questions of the people that attended about certain points in the slide decks and finding out that the people attending did not think a question was needed or they cannot remember what was said.

Probably the biggest revelation out of this year’s Community Meeting was from the Qualified Security Assessor/Approved Scanning Vendor (QSA/ASV) session the day before the Community Meeting started.  It seems that the Council has finally addressed with v3 the message a lot of Qualified Security Assessor Companies (QSACs) have been putting forth regarding the time it takes to write a Report On Compliance (ROC).  Those of us complaining have argued for years that the ROC writing process occupies too much of a QSA’s time (anywhere from 50% to 70% of a project).  As a result, under today’s Reporting Instructions, QSAs tend to worry more about what to write than making sure their client is actually compliant and advising that client how to better maintain compliance.

The ROC will now have an overall ranking for the entire requirement that is a check box that indicates whether the requirement is ‘In Place’, ‘In Place with Compensating Control’, ‘Not Applicable’, ‘Not In Place’ or ‘Not Tested’.  Then under the requirement, will be the tests for the requirement.  It is with each test where the QSA will provide a list of documents reviewed, a list of people interviewed, observations made and sampling selected.  QSAs will no longer have to write meaningless but Quality Assurance approved diatribes regarding a test.  All that will be needed is a list of documents, a list of persons interview, a list of observations made and a list of samples taken.

Now before some of you go nuts about the check box, the Council has not adopted a check box assessment approach.  QSAs are still required to conduct their assessments in a process similar to what is conducted today for a PCI DSS v2 assessment.  What the Council is doing is simplifying the reporting generation and review processes.  The Council finally acknowledged the fact that, other than QSAs and their QA reviewers, practically no one was reading the 300+ page tomes that were being produced – even the acquiring banks.  What they are doing is making the ROC easier to review and read as well as lessening the writing requirements so that QSACs can more readily adopt automated systems to facilitate the conducting of assessments and generating the ROC.  The idea is that this will then allow QSAs to focus on assisting their clients with PCI compliance related activities and fold into the ‘Business As Usual’ approach that is being rolled out with v3.

The most intriguing category is ‘Not Tested’.  The Council added this category for those situations where a QSA did not test the control.  This most often occurs when a QSA is relying on a Service Provider’s Attestation Of Compliance (AOC) for that control such as with firewall configuration management, network security monitoring, custom application software development or other services.  The Council also indicated that Service Provider AOCs may also be getting modified so that QSAs and others relying on them can determine what PCI requirements the Service Provider’s AOCs actually tested.

Now the bad news about this great advancement forward.  The Council has no idea when the final version of the Reporting Template will be available.  Since v3 of the PCI DSS will not be finalized until November, they do not yet have a timeline on how quickly after the release of v3 that the Reporting Instructions will be released.  As a result, QSACs will likely not be rolling out PCI DSS v3 assessments until the Reporting Template is released.  One reason will be because of the major changes involved in v3 and, probably the larger reason, because none of the QSACs want to be put in remediation by the Council for creating ROCs that do not meet the Council’s Quality Assurance requirements.

On the new requirements front, there was a lot of discussion within the QSA ranks on requirement 6.5.6 regarding protection and secure deletion of device memory when cardholder data (CHD) or sensitive authentication data (SAD) were stored in memory during a transaction.  As the Council has defined it in the QSA/ASV session, the QSA will interview developers to discuss what they are doing to secure memory and properly delete CHD/SAD.  QSAs will also observe that developers are in fact coding for this condition.  While this requirement will bring the memory scraping threat to light, most of the QSAs I talked with agreed that the proposed testing is not going to actually have any significant impact on the memory scraping threat of vSkimmer, BlackPOS and the like.  And for PA-DSS certified software (v3 of the PA-DSS addresses this threat as well), the horse has already left the barn for those applications.  The bottom line is that memory scraping attacks will continue to proliferate until the software vendors address the problem.

I asked a question about PCI DSS v3 requirement 1.3.7 and how it would impact merchants that have their card terminals connected to the Internet for transaction processing.  Requirement 1.3.7 states:

“Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

System components that store cardholder data must not be located in a DMZ or be accessible from the Internet or other untrusted networks”

My confusion was over how all of the merchants I encounter with card terminals that directly connect to the Internet would be able to comply with 1.3.7.  After all, in most instances, these card terminals store SAD in memory until the transaction is completed.  The Council representatives admitted that the wording in 1.3.7 was a problem and that they would be looking at rewording it because of this and other similar issues that create a conflict.

Finally, the other big discussion topic was ‘Business As Usual’ or BAU.  For v3 of the PCI DSS, the Council wants organizations to integrate the requirements of the PCI DSS into their day-to-day processes and then periodically test that the integration has occurred and confirm that the integrated controls are working.  At the QSA/ASV session BAU generated a number of questions as to what QSAs were expected to test to assess BAU.  The Council admitted that BAU is only a suggested ‘best practice’, not a requirement, which placated a lot of the audience.  But if you think about it, if an organization desires to be PCI compliance, BAU should already be occurring in the organization.  This is obviously a reminder to organizations that do not get security to provide an incentive for further integrating security practices into their day-to-day processes.

As usual, there was a lot of information sharing between QSAs, ASVs, POs, card brands and the Council at this year’s Community Meeting.  The Council members seemed more relaxed than at the roll out of v2 three years ago.  Hopefully the roll out of v3 will go much less eventfully than v2.




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

October 2017
M T W T F S S
« Sep    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

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

Join 1,884 other followers