This series of PCI blogs highlights the common PCI remediation issues that most organisations will face as they proceed through remediation for their solutions.  In a previous article, I focused on the confusion that can result when clients are unaware of who they need to satisfy to gain PCI compliance.  In this article, I will focus on data encryption.

Common Frustration –Data Storage Requirements

There is some degree of confusion over how an organisation can store credit card data and when.  Often, clients want to store credit card data because it’s a massive convenience for their customers.  The customers simply provide the details once.  Then, the organisation can automatically repopulate this data for subsequent transactions without having to ask the user for this information again.  It’s tempting to store this data because it can have a very positive impact on the usability of a solution.

A lot of the time, clients are aware that PCI dictates what types of credit card data they can store.  However, clients are often unaware that PCI also dictates when this data can and cannot be stored.  Let’s look at the time-component of storage in a bit more detail.

There are three phases of a credit card transaction:

1. Authorisation – During this phase, your organisation requests and receives authorisation from the client’s credit card issuer to conduct a purchase.  The client provides an authorisation code to verify their identity to their issuer and their issue authorises transaction is complete;
2. Clearing – During this phase, your organisation’s bank and the client’s issuer exchange purchase information.  The client’s bank prepares their credit card statement at this stage;
3. Settlement – Lastly, your organisation’s bank receives money from the client’s issuer for the purchase.  The client’s issuer sends a bill to the client.

PCI allows your organisation to save the credit card data up to the end of the authorisation phase.  Afterwards, you may only save card holder data used for authentication.  However, your organisation may never store the sensitive authorisation data (such as PINs, PIN blocks, CVC data) after the first phase.  Encrypting this data does not take any part of the data out of scope.

As with every rule, there are some exceptions.  Your organisation can save data when it is necessary for troubleshooting purposes.  There are various rules around how you must handle the data during debugging processes.  We can talk to you more about this.

Solution

Data storage requirements are tricky.  You have to look at the time when data is available as well as the nature of the data itself to determine the appropriateness of storage.  To avoid this issue, do the following:

• Avoid Storage If Possible: The best solution to attain PCI compliance is to completely avoid the storage of any credit card data.  It will significantly reduce the scope and costs of attaining PCI compliance;
• Store Appropriate Data at Appropriate Times: Storing sensitive authentication data like PIN’s and CVC’s is always a bad idea.  Never do it beyond the authorisation phase of a transaction.  Encryption will not necessarily take card holder data out of your scope.

At Appsecure, we have expertise in PCI as we have QSA backgrounds.  We can help you understand your data storage requirements and how they relate to PCI.  We can help you avoid the PCI pains that we are publishing in this series.

Questions and Comments?

If you have any questions or comments about PCI remediation, feel free to contact Jonathan Carter at jcarter@appsecure.com.

This series of PCI blogs highlights the common PCI remediation issues that most organisations will face as they proceed through remediation for their solutions.  In a previous article, I focused on the issues organisations face from simply not being aware of PCI compliance.  In this article, I will focus on the confusions around roles and responsibilities for PCI.

Common Frustration –Who Does a Client Need to Satisfy?

A lot of the times, clients have a hard time understanding who they need to satisfy to attain PCI compliance.  It can be very confusing because there are many different players involved in attaining PCI compliance: brands, acquirers, issuers, merchants, and service providers.  Each player has a stake in the client’s solution and may have an impact on the client’s ability to gain PCI compliance.

This lack of understanding can lead to some really painful experiences for the client:

• Unknown PCI Violations – Clients are given advice to remediate PCI violations by a player that is not held accountable or responsible for the remediation.  As a result, the client satisfies the needs of the wrong player.  This may result in power struggles between the different players as each thinks they the correct authority in approving the PCI accreditation process.  The client ends up violating PCI according to the player who is actually held accountable for the requirement.

For example, clients may decide to be proactive and attain PCI compliance without any involvement of a third party such as their acquirer.  The acquirer is the entity that actually acquires credit card transactions from the client for subsequent processing.  At the end of the day, credit card brands hold the acquirer responsible to ensure that their merchants (that’s you!) are PCI compliant.

In this scenario, the client does not consult with their acquirer before trying to verify compliance.  The client hires an independent QSA auditor for verification.  However, the auditor’s opinions differ significantly from the acquirer’s own QSA auditors.  If the acquirer decides to enact their own PCI audit (and many do), it is highly likely that their own audit results will differ from your own (see Series 1 for more discussion on this).  At the end of the day, you must satisfy the acquirer’s PCI needs and not your own.

There is a significant risk that the client thinks they are PCI compliant when, in reality, they are not.  They have satisfied the wrong player’s needs.

Solution

When attaining PCI compliance, most of our clients should do the following:

• Understand Accountabilities: Determining who is held accountable for an assessment will have a big impact on determining whose needs you must satisfy.  Determining who is accountable and must enforce compliance is not as straight forward as one would like to think.  You must independently determine who is driving the need for compliance.  They are the ones that you must keep happy.
• Form Consensus: Before attaining PCI compliance, insist that the other players (acquirers, service providers) are aware that you are checking for compliance.  Everyone must agree to honour the assessments of a particular QSA before proceeding.

At Appsecure, we have expertise in PCI as we have QSA backgrounds.  We can help you understand who you need to keep happy at all times.  This will help you avoid the PCI pains that we are publishing in this series.

Questions and Comments?

If you have any questions or comments about PCI remediation, feel free to contact Jonathan Carter at jcarter@appsecure.com.

This series of PCI blogs highlights the common PCI remediation issues that most organisations will face as they proceed through remediation for their solutions. In a previous article, I focused on the pitfalls associated with inconsistent PCI results. In this article, I will focus on the common issues around the enforcement of PCI.

Common Frustration – Too Little Too Late

I see a very common and troubling pattern of behaviour in small, medium-size, and even enterprise-level organisations that plays out all too often.  Organisations design and build sensitive solutions without the slightest regard for PCI standards.  Once the stakeholders fail to include the appropriate PCI requirements, Engineers and Designers implement, test, and release the solution in a production environment.  A year later, a bank comes knocking on their door and demands that they comply with PCI standards.  In response, the organisation panics and the arm twisting begins.

When an organisation reactively responds to PCI compliance, several outcomes may follow:

·         Damage to Reputation – If the media communicates to the general public that your solution is in violation of PCI (a known security standard), the general public may interpret this as an active disregard for their security in favour of corporate profits.  This is rarely the situation but this is how the general public may interpret this;

·         Internal Costs to Retrofit Solution – Your solution may have to be entirely redesigned or significantly tweaked to satisfy PCI requirements.  This may be prohibitively expensive for your organisation;

·         Bank Fines – Banks can be fined by the card brands if your solution is not PCI compliant.  Banks will fight to ensure that your solution is PCI compliant to keep themselves safe from receiving fines by the card brands;

·         Nothing At All  – You and the bank may simply agree to wear the risks that result from PCI violation.  An attacker may hack your solution and compromise the credit cards of millions of users.  An attacker may not.  It’s a roll of the dice.  It will be very rare for a bank or other PCI enforcer to simply look the other way.  They have a lot to lose.

·         Bankruptcy – You may convince yourself and the bank to simply postpone fixes and roll the dice.  If an attacker succeeds in compromising your solution at this phase, it’s a huge gamble.  Personally, I have seen more than a few small to medium-sized organisations go out of business after the attack occurs.  Their size and reliance upon banks as users of their solutions gives them a higher risk due to their reliance on a select few.

This pattern typically unfolds because project managers do not include the appropriate project stakeholders (for example, a Security Architect with QSA training) during the initial conception phase of the project.  During this phase, project stakeholders must specify the solution’s business requirements. Once the requirements are not included, it is logical to see future fallout.

Solution

Most organisations should do the following:

·         Develop a PCI Education Programme - It is a very good idea to develop and communicate a very simple compliance message to all of your organisations’ project managers and system owners.  It should outline when it is appropriate to include PCI resources when developing a solution.  It should also educate them as to the risks of not doing so.

·         Include QSA Security Architects – Include a security architect in each relevant project that has a QSA background or has done some PCI work in the past.

At Appsecure, we have security architects with QSA backgrounds that can help ensure that you avoid the PCI pains that we are publishing in this series.  We also develop and deliver PCI-awareness courses for our clients.

Questions and Comments?

If you have any questions or comments about PCI remediation, feel free to contact Jonathan Carter at jcarter@appsecure.com.