Since the inception of the Data Security Standard, the goal has been a simple one: Increase the security across stakeholders who process card data, be it the acquirers, the merchants, e-commerce sites, systems creators and so forth.
Now on iteration 3.2.1, there has been adjustments to the standard to bring it in-line with current best-practises and also to update certain dates and deadlines (Note: I tweeted to @PCISSC regarding the summary of changes 3.2.1 because they say they’ve removed July 2018 as a due date as it has passed, but it is only May 2018. Also, Section A2 in the PCI DSS 3.2 mentions June 2018) so that it is now better aligned to where companies are going and how they will deliver on their PCI compliance.
So what has changed? The changes are primarily date-based with dates being removed or updated. SSL (Secure Sockets Layer) is in focus a lot with updates to where companies should be by now with regards to deploying SSL and/or encryption in various payment-related services.
Multi-Factor Authentication (MFA) now becomes mandatory, from being a compensating control, and this should be the minimum any company has on a transactional system or any system with sensitive information (GDPR scope included). Of course, the intricacies of how you implement MFA need proper architecting, choosing the right system and implementing it effectively.
We often come across companies interested in implementing PCI DSS requirements, however in many cases the positive aspects of doing so are downplayed by companies who simply want to check boxes to show PCI Compliance. I said it before a very long time ago but the DSS is not just there to tick-off items and claim perfect security simply because one can now say they are aligned to a body as big as the PCI council. The DSS is a framework – you need to build on it, make it work for you and more importantly continue adjusting and fine-tuning it to stay abreast of the security industry and related threats.
There are still numerous concerns with payment systems, card acquirers , and related data that need to be addressed. In summary they are;
- Infrequent use of secure communications with SSL certificates or other means when transferring card data between systems.
- Insecure storage of card and payment data – not only in databases but in log files such as Apache/NGINX logs where logging is turned on for POST data (usually for debugging).
- Voice recordings not stored securely where a user has provided payment information over the phone.
- Insecure storage buckets on AWS and other similar services with payment data in various forms.
The list is not comprehensive, but we’ve seen many examples of the above and it stresses the importance of using the DSS as input into a properly created and managed security roadmap. To simply check tick-boxes and assume you’re secure is going to end badly for both yourself and your customers.
On the up side, many companies are using the PCI DSS like it should be, and they are showing positive results in the security landscape. Yes, 100% security is just not possible, but you can get very close by using various frameworks and constantly building on your security landscape.
To those of you who are doing that, a hat tip for helping keep your clients and their data secure.
-Dimitri Fousekis, CTO, Bitcrack Cyber Security