I've been involved with PCI DSS since virtually the beginning, through work with a number of large Internet Payment Service Providers I was responsible for designing and implementing solutions which would accomodate some of its more specific requirements.
It's fair to say I have a love/hate relationship with PCI DSS and in this, the first of two posts, I'm going to explore my love of it. I think you can probably guess what the other post is going to be about. I'm not going to put forward any of the counter-arguments in this post so you'll need to read both to get the balanced view.
If you're unsure what PCI DSS is or how it may apply to you, we have published a high level overview of card payments and the PCI DSS here.
Raising Awareness
So what's to love about PCI DSS? Well, as with any compliance requirement it's going to get the attention of a company's board. "Attention" being that thing that we security professionals are trying hard to achieve all the time. So raising awareness of security issues; PCI DSS does that. Executives realise that they are going to have to evaluate their security practice and even spend some money to make improvements in a lot of cases. With PCI DSS as a compliance requirement, organisations which may have struggled to secure funding and focus are suddenly able to make a host of overall security and operational updates. This has led to improvements in policies, processes, infrastructure, physical controls and overall awareness of card data security. It all sounds great right? We'll come back to that in a later blog post.
Something is better than nothing
Well, in information security terms this is probably true in many cases. PCI DSS is a very prescriptive standard in a lot of respects, forcing even small merchants to consider security techniques that otherwise they may not. As independent consultants we work with many businesses who just aren't sure where to start. Many produce in-house web applications but their developers have never heard of Cross-Site Scripting, Injection flaws or any of the other common security risks on the OWASP Top Ten, let alone OWASP itself.
PCI DSS explicitly requires that companies develop in-house applications in accordance with widely available secure coding practice and cites OWASP and SANS specifically. So PCI DSS, if you do it right, gives you the opportunity and buy-in to create a secure development training programme, school your developers in doing things the "right" way and introduce them to the consequences insecure code brings.
It's certainly possible to write insecure code and still be PCI DSS compliant but isn't it surely better to have a development team who are aware of the core principles of secure development? Realising that you can't trust any input to your application is really the first step on a long journey, but it's an important one.
Ooh, shiny
Like most information security professionals who have to deal with compliance, I'm dismayed at the number of "compliance-in-a-box" products being churned out. Hey, I understand basic economics, there's no supply without demand, but seriously, there's no box for this. If you can see past all this nonsense and look at the standard for what it is you've actually got a huge number of process and documentation requirements and very few actual software/hardware ones.
This is good. What is going to save your company's data? That shiny IPS box with flashing blue lights or your staff following good security processes, reviewing logs and making educated decisions based on solid incident response procedures? That's just one example and PCI DSS requires you to have these types of procedures in place. It's surely difficult to argue with that isn't it? It has to make a positive difference.
Real world examples
Let's take a theoretical situation, ignore PCI DSS for a second and consider the following requirement from a security architecture perspective. Your IT Manager comes to you and says he needs to allow his Unix guys remote access to one of their Unix servers. The server is hosted in some remote datacentre.
After you've ascertained what's on the server and are comfortable that it can be Internet facing, what's on your checklist for allowing this access securely?
* Unique usernames for each engineer?
* Encrypted protocols only, probably SSH or SSH over a VPN?
* If it's SSH you'll want to use Public Key authentication only - so, Two-factor authentication ensuring engineers have passphrases on their keys?
* No direct root logins?
* Firewall off any other services not required?
* Remove any software you don't need?
* Make sure it's patched
* Make sure this host is in the DMZ, not the internal network?
* Ship logs to a central syslog server and monitor logins?
* Perform a remote scan to ensure you've left nothing silly available?
I could go on further but you get the idea. These are the sorts of things most security guys are going to say and they make sense. You'd be in pretty reasonable shape if you did all those things.
Well, PCI DSS is going to make you do all of those things. It's hard to criticise that.
What about designing a network to host a web application with a baackend database? How would you lay it out?
* Put the webservers in a DMZ?
* Place the database server on an internal network behind a further firewall?
* Only allow connections to the database server from the DMZ?
* Not permit direct Internet connections from the database network to the Internet, only the DMZ?
Again, these are just basics but they're likely on most security architects layered defence checklist. I probably don't need to say it but, PCI DSS will make you do this stuff.
Summing up
So, I've touched on a few of the positives of PCI DSS so far. It gives companies the impetus to implement a good security approach where perhaps they otherwise wouldn't. It opens the door for the information security team to get some valuable improvement done but it still takes a lot of work to implement solutions which actually improve security. For this reason I love it. I wish it wasn't the case but I'm a realist. If this is what it takes for companies to think about security then so be it.
PCI DSS is criticised for providing only a minimum baseline but, in its defence, that's exactly its purpose, the minimum. PCI DSS is guilty of far worse failings than that and in my next blog post I will explore my views on some of these.
On that note, the point I want to leave you with is this:
For all the apparent positives of the above, what is it focused on? Protecting card data. Is protecting card data the only data that needs protecting above all else? For almost all businesses the answer is no.
So is any of this actually improving your overall security? Well, maybe but maybe not. It's up to you to take the things which PCI DSS is asking you to do and squeeze every last drop of security value out of it while the budget and business focus is there.
Implement policies and procedures which cover PCI DSS but also cover the things that matter to your business. Design a network architecture that supports PCI DSS but which can also host the servers and data which really matter to your business.
Check out my next blog post as I dive deeper into the murky waters of PCI DSS compliance and expose it for what it really is.
No comments:
Post a Comment