Seven Lessons Learned from PCI
OutworX became a PCI-capable development organisation quite some time ago. Those who have trod the road to PCI compliance know that it is not an easy task. Here are some reflections on lessons we learned along the way, these will help you:
1. Read the PCI Specs Yourself
You’ll often see the PCI DSS (Data Security Standsummarisedrized by 12 points. But each of those points contains many more requirements within it. Before you are done, you will actually need to deal with several hundred requirements. You’ll need to read the specs to find out all of your obligations. You’ll also need that knowledge to judge how well your internal team and partners are doing on PCI compliance.
You can find the PCI specifications here.
2. Get Advice From an PCI QSA (Qualified Security Assessor)
As you implement PCI, you are going to have questions. Have a QSA firm onboard early to help you through the process and answer those questions. There are many good firms out there. We worked with Coalfire, and found them helpful. Trustwave also has PCI programs.
3. Train Your Developers (and Keep Training Them)
Most developers are not trained in secure coding practices. You’ll have to train them, or they simply won’t be able to produce the secure code that is required.
We used online training available from the Coalfire partner AppSec Consulting.
The gold standard in security training is the SANS Institute. Their courses are more in depth, and also more expensive.
Since the threat landscape is always changing, you will need to periodically give your developers additional training.
4. PCI Transforms Development and IT
PCI is not something that you merely add on to your development and IT (or your DevOps). It is something that changes the way you work.
Developers must always be conscious of security in their designs and coding. Security needs to be baked in, and not added as an afterthought.
Likewise, IT has to be good at security. They’ll need an arsenal of tools to harden systems, keep patches up to date, and look for breaches. They’ll need plans to respond to breaches, and should know what outside security firms to go to if they need help. They will need to consider PCI and security for every new system and network that is in scope for PCI.
PCI takes most developers and IT people to a much higher level of security awareness, and demand a lot from them.
5. PCI is an Ongoing Commitment, not a One Time Checklist
Here is where many companies miss it. It is easy to make a long checklist out of the PCI requirements, to focus on just barely meeting them for the audit, and then forget about them until the next audit. But this is the wrong approach.
The goal of PCI is to create a secure environment that protects credit card data. And that is not a one time (or yearly) event but an ongoing process that takes continual effort. The bad guys are constantly working on ways to break in. You need to be constantly working on keeping them out.
6. PCI Requires More Time and Money Than You Originally Planned
We under estimated the amount of time and money needed to achieve compliance. We have seen other companies do the same. So don’t be surprised if you wind up dedicating more resources to PCI than you originally anticipated. Keep the ultimate goal of security in mind, and you’ll make it.
7. A Touch of Security Fanaticism is a Good Thing
The bad guys are very good at what they do, which is breaking into your systems. So don’t be afraid to be somewhat fanatical on security. Don’t be complacent or take short cuts thinking, It won’t happen to me. If you read about a vulnerability that was exploited, and you know that you have that same one, then fix it ASAP. Secure your systems the best you know how, and then look for ways to make them even more secure.