Author Archive for PCI Guru



24
Mar
18

When A Client Refuses To Provide Evidence

As a QSA there are occasions when a client tells you that you cannot be allowed to have copies of evidence.  The most common occurrence is with firewall and intrusion detection/prevention configurations.  But there are odd instances as well for things like software development lifecycle documentation and information security policies where it makes no sense.

As a “recovering” penetration tester, I get some of these requests.  I once got into a financial institution because their network engineer wanted advice on their firewall configuration and posted the configuration on a forum for people to provide advice.  So, people are right to be concerned.  That said, qualified security assessor companies (QSAC) are required to provide a secured storage area for storing client evidence, so it’s not like evidence is stored just anywhere.

To be clear, a QSA is required to obtain evidence that supports their assessment of the PCI DSS requirements.  The reason is for the PCI SSC’s assessor quality management (AQM) process.  The Council has the right to review not only the redacted Report On Compliance (ROC) and Attestation Of Compliance (AOC), but also the evidence that supports the ROC.  This has always been the case under the AQM process, but it has only been recently that the Council has started exercising that right and reviewing samples of evidence.

Regardless of all of these precautions and requirements, there are still those times when a client refuses to provide copies of the evidence.  What is a QSA to do?

The Council has provided QSAs with an option when this situation happens, it sounds simple, but is not always as simple as it appears.

When a client refuses the QSA to leave with the necessary evidence, the QSA must then require the client to securely store the evidence reviewed for a maximum of three years and agree to make that evidence available if the Council pulls their ROC for review under the QSAC’s AQM.

The key to this solution is that they client must store exactly what the QSA reviewed for a period of three years.  In the case of a firewall configuration, the client needs to create a human readable file (i.e., text, PDF, screen shots, etc.) and then store that file securely either on their network, a CD/DVD or even a USB thumb drive.  A lot of clients create an encrypted archive for storing this information which is a very good idea.  I have heard of a few situations where the client misplaced the archive resulting in a finding against the QSAC for not being able to provide the evidence to the PCI SSC for review.

This evidence solution is likely outside of the original contract with the QSA.  As a result, the QSA will have to make an addendum to their original agreement to cover this situation.  Expect a bit of legal work to come up with getting such an agreement and getting the client to agree with it.

But suppose the client refuses the conditions of the addendum.  What then?

This is where the client’s acquiring bank comes into the picture.  A client’s acquiring bank is required to arbitrate such disputes between QSAs and their client.  Whatever the acquiring bank decides, the QSA needs to make sure that they get the decision in writing (e.g., email, letter, etc.) and put that decision in with the rest of their evidence.  A QSA should also write up a brief memo to provide the background of the situation so that anyone going back and reviewing the evidence understands what happened and therefore has some context as to why the bank issued their decision.

There you have it.  Another situation addressed.

Advertisements
17
Mar
18

Can Every Requirement Be Met With A Compensating Control?

“In theory, theory works.” – Jeff Hall

Some years back, the PCI SSC came out at the Community Meeting and stated that every PCI DSS requirement could be addressed by a compensating control worksheet (CCW).  A rather broad statement but it started a bunch of us in the PCI community thinking, “Is that really the case?”

Before reading this post, I highly recommend reading my post on writing CCWs so that you can fully appreciate why not every requirement can be met by a CCW.

That said, it turns out that there are a lot of requirements where there is no way to develop a CCW.  Here are just a few examples.

1.1.2 – Network Diagram(s) and 1.1.3 – Data Flow Diagram(s)

What would be the mitigating controls here?  There are none because diagrams are diagrams.  There is nothing you can do to compensate for these missing other than provide them.

1.1.6 – Firewall Rules

As with 1.1.2 and 1.1.3, what could possibly serve as a mitigating control?  If the firewall rules are not able to be reviewed, there is nothing you can rely upon to go above and beyond the control.

I have had people suggest that the QSA could rely on Nmap and vulnerability scans of the firewalls.  But that does not necessarily confirm all of the ports/services that are configured for the firewall nor does it necessarily confirm that the devices using those ports are the same ones that are in scope for PCI compliance.

1.2.3 – Wireless Networking

QSAs have repeatedly been told that this requirement can never be marked as ‘Not Applicable’.  The QSA is required to respond to how they confirmed at wireless was either in or out of scope.  But can you create a CCW for these requirements?

The controls that you need to assess to meet these requirements are the same controls you have to use in the CCW for mitigation.  So, if you have to document and evaluate the controls regardless, why would you bother to write a CCW?  You would not.  You would document and meet the requirements and move on.

3.2 – No Storage of SAD

This is the requirement that started the whole CCW debate.  When the PCI DSS was originally issued, QSAs were trained that this requirement could NEVER, EVER have a compensating control.  But that changed when the Council issued their proclamation a few years back.  But is that really the case?

Remember, a CCW must go above and beyond the intent of the original requirement.  3.2 also states in a note that SAD cannot be stored even if encrypted.  Encryption would be the only mitigating control available to an organization that wants to store SAD.  So what replaces encryption if that cannot be used?  Tokenization by a third party would be an option, but if you go that route, you are not storing the SAD, so the discussion becomes moot.

8.3 – Multifactor Authentication

Some form of multifactor authentication (MFA) is required for non-console administrative access to cardholder data environment (CDE) systems and remote access to an in-scope network.  Since the Council has clearly defined MFA and also knocked down multiple logons with different credentials, what is left?  In the end, there is no way around meeting this requirement other than doing what the requirement states.

10.1 – 10.3 and 10.6 – Log Data

Here is another example of where there really is no way to write a CCW.  You are either gathering log data (centrally or on individual systems) or you are not.  You are either reviewing the log data daily or you are not.  Then there is the requirement of sending log data from internet facing devices to an internal device.  No matter how creative you think you are, there are no controls that will mitigate this situation and also go above and beyond.

As I said at the beginning of this post, these are just some of the examples where a CCW is just not going to make it.  So, the next time you think about meeting a PCI DSS requirement by using a CCW, make sure you understand the requirement and that there are controls that will mitigate the risk and go above and beyond the original intent of the requirement.  You will save yourself and your QSA a lot of time and consternation.

17
Feb
18

Pre-Authorization And Post-Authorization (Part 2)

I discussed the concept of pre-authorization in a prior post.  Now it is time to cover post-authorization (aka “post-auth”) and the PCI requirements it drives.  Post-authorization is where the PCI DSS got started even though pre-authorization was always present.  That is because it was in post-authorization where merchants were losing cardholder data (CHD).  While this post is mostly about post-authorization, it still contains some important references and points about pre-authorization.

Post-Authorization

First, let us define what we mean by “post-authorization”.  Post-authorization starts immediately once a transaction has been processed and the payment has either been authorized or declined.  It is at this point that only the cardholder name, PAN (encrypted or tokenized) and expiration date are allowed to be stored in any post-authorization systems.

On page 8 of the PCI DSS, the PCI SSC provides an excellent chart on what can be retained and what must not be retained in post-authorization.

Post Auth PCI DSS Chart

However, this chart also creates confusion regarding pre-authorization and post-authorization because it is not labeled as such and that the discussion on this topic occurs after the chart, not before it.  The following is from the second paragraph following the chart and is usually missed.

“Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment. Organizations should contact their acquirer or the individual payment brands directly to understand whether SAD is permitted to be stored prior to authorization, for how long, and any related usage and protection requirements.”

The first sentence makes it very clear that SAD must never be stored post-authorization.  The second sentence is to ensure that those entities that tokenize/encrypt the PAN do not think they can store SAD because they technically no longer have the PAN (believe it or not, people do think this is true and then claim it as such).  The last sentence was added to tell merchants to discuss with their acquiring bank whether or not they can store SAD as pre-authorization data.  While technically the merchant should have explicit approval from their acquirer for storing pre-authorization data, I can tell you from experience that very, very few merchants have such evidence.  Not so much because they did not ask (most do not), but even more so because acquiring banks do not recognize their responsibility for providing such approval and therefore are reluctant to provide it.

From a post-authorization perspective, any merchant that is storing SAD in a point of sale (POS) solution as pre-authorization data needs to have a secure delete or destruction process in place to remove the pre-authorization data once the card transaction completes (approval or decline).  But a very important point is that pre-authorization data stored for customer convenience in pre-authorization applications is not affected by this change in status.

For the fuel station example in the pre-authorization discussion, the POS system that is storing the encrypted SAD/CHD while you pump the fuel needs to securely delete that information when you complete pumping and the payment is processed.  In some cases, when you swiped your card at the pump, the system not only did the pre-authorization of your payment, but it also may have tokenized your PAN and now is holding that token, not the SAD/CHD.

To continue on with our hotel example.  The hospitality management system is going to pre-authorize payment and then either encrypt the PAN on that initial swipe/dip at check in or it may tokenize it for storage.  At check out, the PAN is either decrypted or the token is submitted for payment.

Most phone orders have the CHD directly entered into systems no different from any consumer buying something over the internet.  In fact, for a lot of call centers, the order is actually entered into the same Web-site that consumers use.  After all, why reinvent the wheel?

However, with telephone orders, there are going to be rare instances where systems are not available.  In those cases, merchants can take a couple of approaches.  During such an outage, I have clients that do not accept orders.  They tell their customers to call back later when systems are operational.  I have other clients that will take the order on a paper form in the name of customer service.  The forms are securely collected and stored until systems are back online.  The forms are then entered into the system(s) and then the people follow secure destruction procedures of the forms.  The important lesson is that either approach can be used depending on your organization’s customer service desires.  The only issue is ensuring security of the information if you choose the manual form approach.

For facsimile and mail order examples we definitely have the issue of the SAD/CHD existing on paper.  So you need to do something to secure that SAD/CHD once the form has been processed.  For facsimiles, the PCI DSS requires a secure facsimile solution be used.  The simplest way is to have a dedicated facsimile machine that is only used for receipt of orders.  This facsimile machine needs to be placed in a locked room or a locked cabinet so that only authorized personnel can access the facsimiles that come to that machine.

On the more automated side, I have seen simple solutions that utilize an outsourced facsimile solution through a secure gateway.  Customer service personnel can only view and print out the facsimiles to process them.  I have other clients that have sophisticated solutions that start out similar to the secure gateway, but the gateway delivers the facsimiles to secure printing solutions that allow the customer service person to use any printer on the network because they can only print after physically going to a printer and tapping their facility access card against a reader connected to the printer thus securing the output until the user is ready to print it.

In the case of mail orders, those require securing the mail upon receipt in the mail room from the post office.  The orders should be secured until they are picked up by customer service personnel or whomever in the organization is responsible for processing mail orders.  Only a limited number of customer service personnel should be allowed to pick up the mail at the mail room to take to the area for processing.  When picking up the mail, the person picking up should sign a log indicating that the mail was picked up, when it was picked up and by whom.  Once taken back to the processing area, the mail needs to be secured there until it is processed.

The easiest approach is what I call “Sharpie redaction”.  That involves using a black ink permanent marker (i.e., a Sharpie marker) and redacting the PAN to the last four digits, blacking out the three- or four-digit card verification code (if provided), copying the redacted form so that the redacted information cannot be read, filing away the copied form and destroying the original by shredding it.

To avoid the “Sharpie” approach, merchants are modifying their mail order and facsimile forms so that the portion containing the SAD/CHD are either at the top or bottom of the form and can therefore be torn off and securely shredded leaving the rest of the form able to be retained without the SAD/CHD.

These are all just examples.  There are many more ways that can also work.  But I prefer simple methods as that is always the easiest to implement and follow.

The bottom line is that, regardless of pre-auth or post-auth, the data needs to be kept secure and the processes used to secure it need to work in your organization consistently and effectively.

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.

11
Dec
17

Q4 2017 QSA Update

On December 7, 2017, the Council held their last QSA Quarterly Webinar for the year.  The following are the more notable tidbits offered up that should be passed around so that everyone has the information.

The Next Revisions Of The PCI DSS And PA-DSS

Emma Sutcliffe had a quick discussion of updates to the PCI DSS and PA-DSS.  There will be an update to both in 2018 once the June 30, 2018 deadline passes.  These will be minor releases (i.e., v3.3) and will change the coming best practices deadlines in 2018 and make them full requirements.  There is a great post on Optiv’s blog site that covers all of these.

During the Q&A portion of the meeting Emma did say that the Council expects a full release of both standards (i.e., v4.0) to come sometime in 2019.

This of course could all change if a breach occurs that is the result of something that the current standards do not cover.  Remember, the SSL/Early TLS issue resulted in v3.2 coming about.

Requirement 11.3.4.1 Clarification

Service providers and their QSAs need to take note of this clarification.  A question that got answered during the Q&A portion of the Webinar was regarding the deadline for 11.3.4.1 in January and how QSAs should deal with that as a new requirement.  What we were told was that as of February 1, 2018:

  • Service providers MUST have a plan, policies and procedures in place for conducting segmentation testing every six months.
  • Service providers MUST have at least one segmentation test conducted that is no more than six months old.

As of August 1, 2018 or six months after the date of the first segmentation test referenced above (whichever date is earlier):

  • Service providers MUST have had a second segmentation test conducted. If your PCI assessment date comes before your six-month segmentation testing date is due, FOR THIS ONE ASSESSMENT ONLY, you will need only the one segmentation test and the policies, and procedures.
  • Going forward service providers MUST conduct segmentation testing every six months, no excuses (and let me tell you, a CCW for this is going to be very ugly to construct).

What was not discussed in Emma’s answer, but I am sure applies, is that when the Council says six months apart, it is 180 days/six months plus or minus five days.  This is no different from quarterly testing where the Council has repeatedly told QSAs that quarterly is 90 days/three months plus or minus five days.  So those of you poor at date math (you know who you are) need to make sure that you follow this guidance as the Council will not give your QSA leeway which means that your QSA will give not give you leeway.

QSA Work Papers

This was an interesting discussion because coming out of the financial audit business, work papers were all part and parcel of the audit process.  As a result, work papers are forever engrained in my life.  But apparently, other QSAs are not necessarily as diligent.  Because this has become such a consistent finding in PCI SSC Assessment Quality Management (AQM) reviews, the Council felt that they needed to spend time on the subject.

The most obvious evidence that QSAs need to retain is the evidence that supports their analysis of compliance.  This includes things such as device configuration files, server configuration files, user lists, screenshots of security applications’ master consoles and log data.  But there is other evidence that is needed as well.

But also needed as evidence are interview and observation notes.  I cannot tell you how many assessments I have reviewed over the years that were missing interview and observation notes.  I have a work paper Word template for collecting meeting notes.  In the document heading I capture the client name, project name, date and the subject of the meeting.  In the body of the document are three sections.  The first section is where I capture the names and titles of the meeting attendees.  The second section are where I capture my meeting notes.  The third and final section is where I capture a list of any issues or follow up items I got from the meeting.

Here is how I take meeting notes.  I use an Excel spreadsheet of the PCI DSS requirements that allows me to filter by section and type such as interview, observation, documentation or sample.  I notate in my notes how I filtered that spreadsheet and then only capture issues or anything out of the ordinary in my meeting notes by requirement being discussed.  That way I am not always scribbling notes and can focus on asking questions.

SSL/Early TLS

As of this meeting, the Council is still holding the line on the June 30, 2018 deadline for stopping the use of SSL and Early TLS (TLS v1.0 and some configurations of v1.1).  If this date is going to change, the Council is being very quiet about it.  My recommendation is you need to do whatever you can to kill off SSL and Early TLS by that June date.

In a related discussion, Emma addressed a question regarding approval to use TLS v1.1.  She stated that people will have to look to the NIST document SP800-52 for how TLS v1.1 must be configured to be considered secure.

08
Dec
17

Deadlines Coming Soon

A good reminder that there are a number of deadlines coming in January 2018.

PCI Requirement Changes Coming in 2018

18
Nov
17

Chrome And Redirects

A bunch of us saw this Wired article the other day and began thinking, “I wonder if this will screw up any of our clients’ eCommerce sites?”

After all, a LOT of eCommerce sites went with redirects to reduce their PCI scope, so there is a big potential here for issues if Google does not get this right.  And if Chrome gets this capability, you know that Edge, Firefox, Safari and the like will not be too far behind in implementing their own version.

I know that Google is saying that it is for dealing with only “sketchy” sites.  But is a checkout redirect going to be treated as “sketchy” once Chrome gets this update?

Should prove interesting once this new version of Chrome hits the streets.  Probably ought to give your eCommerce developers a heads up on this and get them testing your site once this new release is out.




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

June 2018
M T W T F S S
« May    
 123
45678910
11121314151617
18192021222324
252627282930  

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

Join 1,985 other followers

Advertisements