PCI DSS 3.0 has now been out for well over a year so it's time to take stock of how it is being accepted and used, or more to the point, how it's not being readily accepted and used.
I am not going to go through the standard point by point. For those interested, the new Verizon 2015 PCI Compliance Report (http://www.verizonenterprise.com/resources/reports/rp_pci-report-2015_en_xg.pdf) is a great resource and provides a nice evaluation of the new 3.0 standard. Rather, I want to make a singular and simple point. It's time for organizations to stop whining and get on to the business of addressing PCI - no more excuses that the standard is too complex, too hard to comply with, or too contradictory.
Let's take a step back and consider what PCI is really all about. PCI is a security framework in much the same way that NIST 800-53 or ISO 27001 are frameworks. This means that it is intended to offer guidance to organizations without dictating every detail. Why? Because threats constantly change as do counter-measures. And what does that mean? This means PCI should be thoughtfully considered by a qualified security architect and used to integrate meaningful and agile security controls, processes, configurations and policies that will withstand the test of time. This does not mean a security architect can parachute in, create a security architecture and leave. As with any architecture, there will be a fair amount of care and feeding to ensure it continues to function and address new and unforeseen threats, thus the notion of agility.
My point here is very simple. Don't blame PCI if your organization cannot design, implement and manage a security architecture. As the PCI Guru (https://pciguru.wordpress.com/) will tell you, it's all about the execution. Let me expand upon this. Forget PCI for a moment. Imagine if you will that your customers appreciate the notion that any information and not just payment information, they provide to you is kept secure and confidential. I know as a consumer I do. As a security architect I take this to heart and want to build the best security architecture I can, as I know this will provide my company with a competitive differentiator. To get there I must execute and do so in such a way that I address all relevant security, technical and business requirements. In short, stop thinking of PCI as a line-by-line checklist of security requirements and instead understand it's intended to be a baseline framework of good security practices.
Let's take a closer look then at how security architects and their organizations achieve proper execution. Here are a few examples:
Security awareness. PCI has a lot to say about security awareness so let's think of it from the perspective of PCI as a framework and how to execute from that. Our security architect gets to work on a security awareness program and makes sure everyone understands their role in staying secure. Things go great for a few months and then someone opens an email attachment with a malware payload. Do we blame PCI? I don't think so. The issue here is that the basic notion of security has not been effectively integrated into the mindset of some users. That is a failure to execute.
Code defensively. This is one of my favorites. PCI, nor any other security standard or framework, should not need to dictate exactly what threats one should be aware of when coding. What developers should be doing is coding defensively. By that I mean, for example, is code your SQL calls with proper logic that only allows whitelisted or valid queries to be made. Not coding defensively is a failure to execute.
New technology. So what does this mean when new technology is introduced? Take mobile payment security as an example. Recall I mentioned that security architecture should be agile. With a reasonably agile security architecture we can introduce new technologies without too many complications. The security architect will need to consider the application and its interfaces, how these are tested and most importantly, how the application is integrated with the existing infrastructure. From a fundamental process, development and integration standpoint, this effort should be no different than what is needed to implement any new application. Again, this is a matter of execution.
Tags:
