Skip to main content

The PCI DSS and Why It's Relevant to Everyone

Many of you will know that PCI DSS stands for the Payment Card Industry's Data Security Standard and most of the rest of you have probably heard of it and wondered what it was. You may immediately say I'm not interested in the Payment Card Industry and want to navigate away, but just before you do, you should know that many of the 12 recommendations are relevant to all. Actually the PCI DSS recommendations are mostly common sense that we should all be implementing anyway. I'll give a quick overview of the big 12 and how these can be applied to all networks in this blog.
According to the PCI Security Standards Council, "The core of the PCI DSS is a group of principles and accompanying requirements, around which the specific elements of the DSS are organized." The 12 recommendations that they put forward can be generalized as follows and should be adhered to by all organisations:
  1. Install and maintain a firewall configuration to protect private/sensitive data
  2. Do not use vendor-supplied defaults for system passwords and other security parameters
  3. Protect stored data
  4. Encrypt transmission of private/sensitive data across open, public networks
  5. Use and regularly update anti-virus software
  6. Develop and maintain secure systems and applications
  7. Restrict access to private/sensitive data by business need-to-know
  8. Assign a unique ID to each person with computer access
  9. Restrict physical access to private/sensitive data
  10. Track and monitor all access to network resources and private/sensitive data
  11. Regularly test security systems and processes
  12. Maintain a policy that addresses information security
Dealing with each very briefly, I’ll try to show how these can be applied to a ‘normal’ network rather than one involved in dealing with payment details. Firstly, we all know that we must have a firewall and block access from the outside world. However, just having a firewall isn’t enough, if it isn’t configured and managed properly. Every port and service open through it must be justified and have clear documentation. There must be policies and procedures in place to control the opening of ports and services through the firewall so that each one can be assessed for its impact on the overall security. Wireless networks should also be separated from wired networks by the firewall – this doesn’t mean that the wireless network has to be unsecured from the Internet or that it has no access to the wired network, just that restrictions and filtering should be in place between them. Obviously, there should be no access from outside the network into the network, as a DMZ should be set up for all public access machines. Finally, personal firewalls should be installed on all mobile machines and hardware firewalls installed at users’ home premises if external access is to be allowed.
The second should be obvious and doesn’t really need any explanation, other than to say disable as many features as you can and don’t allow any configuration or management from outside your network. There are ways to enable secure remote access to the network, thus allowing for management of servers and devices to be achieved from within the network.
The third and fourth requirements go together and mean that strong authentication is required and permissions set appropriately. However, we should also implement encryption on highly sensitive data and removable devices/mobile machines, with proper key-management processes, and Digital Rights Management (DRM) to prevent digital leakage. All data transmitted across public networks should be encrypted (whether sensitive or not).
Is there anyone who doesn’t follow point 5? You’d also think that the zyxst (6th) recommendation would be followed by all organisations, but this isn’t the case. You must have proper patch management procedures as these are critical to securing potential vulnerabilities. However, how many times do you see that the state of the server or service is lagging behind the latest patches? I have seen many commercial outfits developing web applications that are not secure as security is an afterthought and not embedded in the development cycle. This means that, even if you don’t write your own applications, you must check third party applications that you intend to use on your network. Make sure that they have been developed using secure coding guidelines and have been independently tested. An example of not taking it for granted is Apple, who has no formal security program (ref.).
The seventh recommendation sounds obvious again, but it isn’t followed even by many of those covered by the PCI DSS. Restrict access to your data by business need to know. Does your network administrator need to know everyone’s personnel details and payroll? No, so make sure they don’t have access. This is an often overlooked problem, but many organisations rely on people not looking rather than actually protecting the data. How many examples can you quote of companies, and government organisations, losing confidential data that they should never have been able to access? An example springs to mind of a large retailer that lost the names, addresses and credit card numbers of millions of customers, which were copied onto a laptop. Why would you need all this data? Presumably you want it for business intelligence purposes and data analysis. This can, and should, be delivered live through secure channels, not done from a local copy. Why do you need their credit card number though? The point is that it shouldn’t be possible to extract this data and store it on the laptop in the first place. The next two are also related to this and a previous point of requiring strong authentication, which means that you must not allow sharing of user accounts by employees (especially executives giving passwords to PAs!).
Recommendations 10 and 11 deal with monitoring and testing the network. In order to make sure that your system is functioning as expected and that your security mechanisms are appropriate and don’t have vulnerabilities, you need to monitor the network and regularly test it for vulnerabilities. Every time a significant change is made to the network, its impact on the network should be assessed and tested.
The final recommendation is to maintain an information security policy. This must cover all forms of information though, not just electronic. It should be very clear and all employees should be trained in its content and abide by the policy or face punitive measures. Employees should have to sign a copy of the security policy, stating that they have read it, understand its content and agree to abide by it. However, this has no teeth if you do not adequately train all of your employees and update them regularly on the policy and any changes.
The PCI DSS recommendations can and should be adopted by all organisations, not just those involved in payment card transactions.

Comments

Popular Posts

You say it's 'Security Best Practice' - prove it!

Over the last few weeks I have had many conversations and even attended presentations where people talk about 'Security Best Practices' and how we should all follow them. However, 'Best Practice' is just another way of saying 'What everyone else does!' OK, so if everyone else does it and it's the right thing to do, you should be able to prove it. The trouble is that nobody ever measures best practice - why would you? If everyone's doing it, it must be right.

Well, I don't agree with this sentiment. Don't get me wrong, many of the so-called best practices are good for most organisations, but blindly following them without thought for your specific business could cause as many problems as you solve. I see best practice like buying an off-the-peg suit - it will fit most people acceptably well if they are a fairly 'normal' size and shape. However, it will never fit as well as a tailored suit and isn't an option for those of us who are ou…

Coventry Building Society Grid Card

Coventry Building Society have recently introduced the Grid Card as a simple form of 2-factor authentication. It replaces memorable words in the login process. Now the idea is that you require something you know (i.e. your password) and something you have (i.e. the Grid Card) to log in - 2 things = 2 factors. For more about authentication see this post.

How does it work? Very simply is the answer. During the log in process, you will be asked to enter the digits at 3 co-ordinates. For example: c3, d2 and j5 would mean that you enter 5, 6 and 3 (this is the example Coventry give). Is this better than a secret word? Yes, is the short answer. How many people will choose a memorable word that someone close to them could guess? Remember, that this isn't a password as such, it is expected to be a word and a word that means something to the user. The problem is that users cannot remember lots of passwords, so remembering two would be difficult. Also, having two passwords isn't really…

Security is a mindset not a technology

I often get asked what I look for when hiring security professionals and my answer is usually that I want the right attitude first and foremost - knowledge is easy to gain and those that just collect pieces of paper should maybe think about gaining experience rather than yet more acronyms. However, it's difficult to get someone to change their mindset, so the right attitude is very important. But what is the right attitude?


Firstly, security professionals differ from developers and IT engineers in their outlook and approach, so shouldn't be lumped in with them, in my opinion. The mindset of a security professional is constantly thinking about what could go wrong (something that tends to spill over into my personal life as well, much to the annoyance of my wife). Contrast this with the mindset of a developer who is being measured on their delivery of new features. Most developers, or IT engineers, are looking at whether what they have delivered satisfies the requirements from t…