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.
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 email@example.com.