Following is an article I wrote and had published in Linux User and Developer Magazine in late 2007, hope you enjoy.

Over the past few years there have been more and more companies have had unwelcome media attention due to Credit Card data theft, you only have to do a quick query on your favourite search engine on credit card fraud and you get an idea of the increasing amount of breaches that have occurred. Some of the more public ones have been the recent TJ Maxx breach, and the Natwest Call centre scams.

All these breaches are obviously not good news, especially for those people whose card details have been compromised. Also if you look at it from the card schemes point of view its not great news either, because the more breaches there are, the more people loose confidence in using their products, and so usage goes down. So naturally the card schemes are looking to do something about it. This was in the form of various statements and standards from them, all slightly different, all requiring different things. This turned out to be a poor strategy from the point of view of the companies where these standards should be interested who were faced with the task of implementing differing standards in their card environment. So in 2005 the card schemes in an effort to create some clarity for people they all got together and PCI SSC was formed.

Some History

So what is PCI you ask? And what does it mean? PCI stands for Payment Card Industry, and when people talk about it they are usually referring to the PCI Security Standards Council, which is the organization that was formed in 2005 and is made up of the various card payment scheme vendors (Visa, Mastercard, American Express, etc). What is their mission in life? To take a quote from their website;

*The mission of the PCI Security Standards Council is to enhance payment account security by fostering broad adoption of the PCI Security Standard
*

So as I mentioned it was formed in 2005 to bring together the various companies to provide a single source of guidelines and standard setting for card payments. Previously each card organization had issued their own differing security guidelines, such as Visa’s Cardholder Information Security Program (CISP), and so an independent organization was created to give a unified, more efficient source of standards and guidance for everyone who had an interest in card schemes.

And so with the formation of the PCI SSC they set to work creating the set of standards and guidelines that people should be following, this they released in late 2005 and it was named the Payment Card Industry: Data Security Standard v1.0 (PCI: DSS for short), this was later revised and an updated version (v1.1) was released in September 2006. The standard is released as a PDF document that is a nice light read of 17 pages in length, containing the definitive reference to what we should be adhering to. In a very high level view though, it consists of 12 requirements, which are;

  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
  • Requirement 3: Protect stored cardholder data
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks
  • Requirement 5: Use and regularly update anti-virus software
  • Requirement 6: Develop and maintain secure systems and applications
  • Requirement 7: Restrict access to cardholder data by business need-to-know
  • Requirement 8: Assign a unique ID to each person with computer access
  • Requirement 9: Restrict physical access to cardholder data
  • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Requirement 11: Regularly test security systems and processes
  • Requirement 12: Maintain a policy that addresses information security

Growing Relevance

The visibility and importance of a company becoming PCI: DSS compliant is growing; in my day job I must get at least a call a day from various companies’ offering solutions to help my client become PCI: DSS compliant. Their sales patter is 9 times out of 10 along the lines of “Our solution will help you meet at least (pick a number) of the PCI requirements, can we come and talk to you about it?”

The increasing numbers of calls I get indicates that IT Solution Providers are realizing that there is a huge market out there under the banner of PCI: DSS compliance, and there is a lot of money to be made. For example from my own experience the costs of getting compliant for the average medium to large UK Retail Chain can cost anything from £500,000 to £3,000,000, and take from 6 months to 2 years to achieve.

The intention for this article is to see where Free and Open Source software can help meet and plug some of those compliance gaps, and was inspired by the sales patter on the calls that I receive. I will be using the PCI: DSS v1.1, as that is the current standard at time of writing (though v1.2 we are told is imminent). As you may gather PCI: DSS compliance is a big subject and volumes could be written on the subject, but hopefully this article will give you enough information to allow you to be better informed, and when your company starts talking about PCI: DSS compliance you will be able to point them in the direction of some solutions from the Free Software community.

Get Scoping

Firstly, I want to say a little about scope or what systems do you have to apply these requirements to? This is one of the first things that you need to understand, if you have 4000 systems (PC’s, Servers, Routers, Tills, etc) going through a PCI compliance programme for all of those is no small task; but if you analyze your systems and process’s and discover that only 30 of them actually hold card data that could seriously reduce the time and effort you need to spend on the initial project, by isolating them and then concentrating on what you need to do on them.

So something that you need to identify as soon as you can is to understand what is your ‘cardholder environment’? The PCI: DSS states the following

*These security requirements apply to all “system components.” System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment.
*

In short, your cardholder environment is any systems that hold card data and any systems on the same (firewalled) subnet. Though this can get tricky when you have a few hundred remote LAN’s with EPOS systems holding card data on them, having to segment those is a costly and time consuming exercise! But if you can make some changes that remove the need for card holder data being held in those systems then you have significantly reduced your scope.

The Requirements

Having given some background into the PCI: DSS, we can now start looking at some specifics. I will go through each of the requirements and look at how Free Software can help towards compliance. So let’s get into it shall we?

Requirement 1 – Install and maintain a firewall configuration to protect cardholder data

Free software has a long history of providing enterprise class firewall features, both from the GNU/Linux IP Tables, and the BSD camp with IP Filter, Packet Filter, etc. Out of the box all Linux distributions have the basic tools to fulfil this requirement, you just need to take those tools and apply them to the requirement.

The PSI: DSS also gives details on how you should be configuring your firewall, by requiring that you implement a deny then allow policy. Any changes to the default deny policy should be justified and documented, specifically anything besides hypertext transfer protocol (HTTP), and secure sockets layer (SSL), secure shell (SSH), and virtual private network (VPN) and any ‘risky’ protocols like FTP.

Maintaining this sort of control over firewall configs, could be implemented by using one of the many version control systems available (VCS, SVN, CVS, etc)

It also requires that you should be running IP Masquerading (NAT) and have a private address space on your internal network, so as to mask internal addressing schemes from the internet. That is easily implemented using IP Tables.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Luckily most Linux Distributions as part of the installation process prompt you to create a ‘root’ password and so there is no such thing as ‘vendor defaults’. Notable exceptions are systems that make extensive use of the ‘sudo’ command, and as such have no password on the root user. There have been many debates on the pro’s and con’s of this approach and we could write a whole article on this alone. In the light of this article and PCI it would probably be advisable on these systems to set a password on the root account, and also restrict who can sudo.

This requirement also asks that you harden your systems by disabling or removing any unnecessary software, drivers, sub-systems, etc. On other systems this might prove tricky, but with Linux it is easy to remove drivers and sub-systems by recompiling a minimal kernel. And unnecessary daemons can be prevented from starting by manipulating the init scripts using tools such as update-rc.d

Another interesting part of this requirement is that you implement one function per server, so database on one, web server on another, DNS on another etc. Because of the stability and power of Linux we are used to having multi-function servers. Luckily because of the nature of Free Software we are free to have multiple servers with no cost impact (apart from hardware).

Also we are required to encrypt any remote access for config, luckily telnet doesn’t (well it shouldn’t!) come enabled on any Linux distributions nowadays, so you may need to install SSH. If you install it make sure you disable remote root logins.

Requirement 3: Protect stored cardholder data

If you must store cardholder data then you need to be protecting it, luckily there are tools in the free software toolset that can help with this.

First of all you need to make sure that you are not storing more than you need, each card has a lot of information, enough so that if you wanted to you could make a copy. You should only really capture the most essential data (usually Account Holders Name, PAN, Service Code and Expiry Date), anything else is unnecessary and potentially dangerous. There are no real tools in the Free Software toolset that can really help with this, as this sort of thing is generally a function of the EPOS software.

Where Free Software can really help is in the encryption of the stored data. It is required that data be encrypted using in one of the following ways.

• Strong one-way hash functions (hashed indexes)

• Truncation

• Index tokens and pads (pads must be securely stored)

• Strong cryptography with associated key management processes and procedures

In a lot of the PCI discussion groups that I am involved in a package called StrongKey is often mentioned. This is a key management package that in combination with good cryptography (AES, Blowfish, DES, etc) meets the last point on the above list.

Requirement 4: Encrypt transmission of cardholder data across open, public networks

This section seeks to combat transmission of card data over what they call open, public networks. They specifically mention Wifi networks, obviously trying to address the wide-scale implementation of unsecured Wifi networks in the business world that seems to have happened with little or no thought to security.

It requires that you should never use WEP as the only security mechanism, and if you do use WEP a number of additional security measures should be implemented. Ideally you should not use WEP, but rather WiFi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS.

Implementing a WPA2 based Wifi infrastructure is possible using Free Software using free RADIUS Servers and Access Points that support WPA2, there are many HOWTO’s on the internet detailing how to do this.

Any company that is taking card data on integrated systems are likely to have several systems, and card data will have to move between them for either central authorization, overnight settlement, or moving to a central transaction database. To protect against that data being compromised you are required to secure that transmission.

Again there are several open source tools that allow you to meet this requirement. Which one you implement will depend on your EPOS architecture, which will also dictate how you implement that tool.

For example one way would be if the data transmission between systems are files sent in batch mode, you could send it using SCP (part of the SSH toolset).

Or if your data is sent in files that are stored in a particular location on your systems, then you could use RSYNC over SSH.

If your EPOS application has its own transmission method that they are unwilling or unable to modify for PCI: DSS (though if they aren’t then I would question their suitability as a vendor), you could use a package called stunnel, this effectively allows you to encrypt application data transfers in such a way that is transparent to the application, with no modification to the application needed.

Requirement 5: Use and regularly update anti-virus software or programs

Good news on this section, the PCI SSC obviously recognize the security that users of *Nix systems have enjoyed for many years. This requirement has the following statement

*Note: Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.
*

So by simply putting your cardholder systems on Linux you can immediately put a tick in the box of requirement 5!

Requirement 6: Develop and maintain secure systems and applications

Much of this system deals with secure coding and development practices, so if you are thinking of starting a Free EPOS project then you should take note of this requirement.

The first point in this section though, states that you should ensure that your systems keep up-to-date with the latest patches and updates from your software vendors, it even goes as far to say that all relevant security patches should be deployed within one month of release. This is something that Linux excels at, with tools like apt, yum, auto-yast, etc. I often describe this to people unfamiliar with Linux as something like Windows Update but for all your software.

A popular approach for companies deploying Debian based systems and something I have done in the past, is to have a private apt repository that all your systems point to, and as well as including upstream packages can contain packages that have company specific settings and packages. Then by having all the end systems with a daily apt-get update; apt-get upgrade you have an up to date infrastructure.

Requirement 7: Restrict access to cardholder data by business need-to-know

Apart from the obvious of ensuring through checks and procedure that only those who need to have access to card data, you need to ensure that people who don’t need access can’t.

Through the use of filesystem permissions you can ensure that only the users that should have access to cardholder data are able to.

Requirement 8: Assign a unique ID to each person with computer access

Everyone who has access to systems in the cardholder environment needs a Unique ID. From their inception back in the 70’s *Nix systems have been inherently multi-user and so this is bread and butter for us.

So if you only have a single system in your cardholder environment then you will be OK with the native *Nix passwd system. Once you have multiple systems you will need a distributed authentication system of which there are several FLOSS options, these include NIS, OpenLDAP & Kerberos.

Requirement 9: Restrict physical access to cardholder data

There is not anything obvious that FLOSS can do to address this requirement, as this is all about physically securing systems, making sure backup tapes are safe and off-site, putting procedures around access to areas with cardholder systems.

Though if we look at section 9.1.1 where it says;

*Use cameras to monitor sensitive areas. Audit collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.
*

Essentially it is saying that you need a CCTV system, of which there is a well regarded FLOSS one in the form of ZoneMinder, which takes feeds from cameras and does everything you would expect from a good CCTV system.

Requirement 10: Track and monitor all access to network resources and cardholder data

This requirement is the Big Brother of the standard, monitoring when and where people go. It requires the introduction of Intrusion Detection Systems (IDS) such as Snort for monitoring the network which is FLOSS in origin, and is a well established IDS, considered as the de-facto IDS.

Another aspect to this requirement is the log management and analysis, which is something companies underestimate as to the effort that is needed to implement. We have had good systems for collecting this sort of data for many years in the *Nix world in the form of the venerable syslog. So build a central syslog server and point all your systems at that. You then need to review all those logs daily and make some sense out of it through some log management solution such as epylog or Prelude-LML

Requirement 11: Regularly test security systems and processes

This requirement demands software that for good or bad GNU/Linux and FLOSS in general have had a reputation for for a a few years, in that a lot of the network scanning tools are assumed to have come from the FLOSS community. It requires that you run, both internal and external network scans and audits, to test for vulnerabilities.

We have several tools for this, and some obvious examples are nmap for scanning network ranges for open ports, as well as the curiously named SATAN. We also have Nessus for scanning for vulnerabilities in systems.

We are also required to implement a File Integrity Monitoring such as Tripwire on systems where card data is stored to monitor suspicious activity on key system files. This is another tool that seems be doing well, as it is often quoted and seems to be the de-facto standard for this sort of tool.

Requirement 12: Maintain a policy that addresses information security

There is nothing much that FLOSS can do to help this requirement as it is about process and IT Governance. You could possibly use Openoffice.org to write the policies in! There may also be room for implementing a document management system such as DocMgr to keep track of policies and signed documents through the workflow functionality in that product.

In Conclusion

So as you can see there are plenty of tools that our community have produced that can stand up there with the proprietary offerings from the various vendors, and go at least some way to addressing a companies PCI compliance needs. As I have mentioned there are lots of companies out there making a good living out of providing PCI compliance solutions and software.

The big push now is for companies to take PCI compliance seriously, unfortunately here in the UK there is little incentive for a company to invest in getting compliant, if you discount looking after your customer’s card data as something that you should take seriously! What puts a lot of companies off is the amount of money that they would have to spend on software and infrastructure in implementing the requirements, but as we have demonstrated you can lessen that blow by using software from the FLOSS community.

If you want to find our more about PCI, I would encourage you to first have a read through of the actual standard itself; this will give you good baseline knowledge. I have also provided a few links of various resources round the web that are good places to go to learn more about PCI compliance.

In closing I would just encourage you to spread the word about PCI compliance, it’s a good thing to do and even if you don’t want the ‘badge’ of compliance, the requirements are all good practice anyway and by working through them you are making your systems a more secure place.

General Websites

PCI Home = www.pcisecuritystandards.org
Visa CISP = usa.visa.com/merchants/risk_management/cisp.html
PCI Compliance Demystified = pcianswers.com
PCI Community Site = www.pcifile.org
Storefront Backtalk = www.storefrontbacktalk.com
PCI Monkey = www.pcimonkey.co.uk

Requirement 1

IP Tables = www.netfilter.org
Subversion = subversion.tigris.org
CVS = www.nongnu.org/cvs

Requirement 2

Sudo = www.gratisoft.us/sudo
Update-rc.d = wiki.linuxquestions.org/wiki/Update-rc.d
SSH = www.openssh.org

Requirement 3

Strongkey = www.strongkey.org

Requirement 4

WPA on Linux = www.linuxjournal.com/article/8017, www.linuxjournal.com/article/8095, www.linuxjournal.com/article/8151
Stunnel = www.stunnel.org

Requirement 5

ClamAV (if you are particularly pedantic) = www.clamav.net

Requirement 6

Apt-Get = www.debian.org/doc/manuals/apt-howto

Requirement 7

Unix Filesystem Basics = www.unix.org.ua/orelly/networking/puis/ch05_01.htm

Requirement 8

NIS = www.linux-nis.org
OpenLDAP = www.openldap.org
Kerberos = web.mit.edu/kerberos

Requirement 9

ZoneMinder = www.zoneminder.com

Requirement 10

Snort = www.snort.org
Syslog = en.wikipedia.org/wiki/Syslog
EpyLog = linux.duke.edu/projects/epylog
Prelude-LML = www.prelude-ids.org

Requirement 11

Nmap = insecure.org/nmap
SATAN = www.sw-technologies.com/net/security/satan
Nessus = www.nessus.org
Tripwire = sourceforge.net/projects/tripwire

Requirement 12

DocMgr = www.docmgr.org