One of the most pressing issues in terms of e-business payment developments must be the PCI DSS certification payment systems and merchants must go through, o, and let’s not forget the banks either. Let’s just get past the acronyms for a moment:
1. PCI – Payment Card Industry is the five main card associations consisting of Visa, MasterCard, Diners, Amex and JCB.
2. DSS – Data Security Standard – The standard that all players within the e-commerce industries must be measured against,and if successfully audited, certified according to their specific role within this industry.
3. SSC – Security Standards Council is the actual team authorized by the PCI members to design these standards for the card industry.
The DSS standard applies to the systems and people within the card industry that handle cardholder data in any way or manner, even if acting simply as a proxy or even a buffer, they need to be compliant.
To me there are basically four components to a successfully audited e-commerce company – securing the network, securing the systems, securing the database and applications, and securing the people processes around cardholder data. Effectively this covers the entire DSS audit requirement, and allows companies to break things down into workable bits.
Basically this requires some hardening exercises and ensuring you have implemented correct password policies and personalized logins too. Key to this process is ensuring that all access is fully monitored, both OS access and physical access. You need to ensure you have personal logins, no generic logins, iow don’t have administrator or root usable to anyone in your organization, and if you cannot remove them, for example root in Linux, simply give them complex passwords and lock the record away in your safe never to be used for daily purposes again. Create authorized users and give them administrative rights to handle those tasks that need admin or root level access. These actions on your servers, routers and firewalls are fully audited at all times, so another good idea is to ensure that the logs are communicated to a syslog server on your network. Another very important thing to remember is NTP on your servers. Make sure these are synchronized, using one unit to access a reliable NTP (Network Time Protocol) service, and setting the rest of your systems up in such a way that they can retrieve NTP from this one unit on the network. Yet another good policy is to ensure all updates, whether OS or Security software, can be retrieved by one server from the different OS/Security sources, and the other servers on your network then set to retrieve their OS and Security updates from this server again. This is not always possible with all types of updates, but at least for those that are deemed security updates by their vendors, must be set in this way, including critical updates from vendors, for example Microsoft.
There needs to be two critical features to your network management policy – one aimed at securing the network and one aimed at monitoring the security of the network. Monitoring is easier to describe in this short post, and may include updates to your syslog server by your network management and monitoring equipment, for example JJFNMS, SNORT, Spiceworks, PandoraFMS, Nagios, and so on. Essentially you need to ensure you can monitor the environment for external and internal threats. Ensure Wifi is not enabled within your collocation or server farm environment. Wifi in the admin area outside this environment needs to be monitored as well, even if you just keep track of the exact name and number of wireless networks penetrating this area of your environment. Ensure that you have secured those under your control too, with proper WPA/WPA-2 security. All systems on your network must have their own security software running and updated daily (Anti virus, Anti Spyware, Anti Mallware, Rootkit detection, and so on), whilst those that are notebooks (mobile use) must have their own personal firewall software active and correctly setup. Routers need to be closely checked to ensure configuration files in use are the same as configuration files saved on the units, or else routers that are reset during power-failures may boot up on an older config file than it was running on before the crash. This is critical especially in terms of some Cisco routers. Obviously ensure that your network is properly segmented and that your firewall or firewalls, depending on this segmentation, has been setup to close off ALL non-essential ports. Where possible try and use secure versions of protocols used to access your systems, for example if FTP is absolutely needed, use SFTP. Try to setup access to your production environment for these protocols in such a way that it is temporary access only where possible. Do not use telnet where possible, especially on production systems. Make sure all that is visible to the outside world is the most essential systems only, and hide everything else behind an iron curtain 😉 Think Fort Knox first and then once you have shut everything down, start looking at bringing only those bits back or opening up ports where something gets broken by the initial shutdown.
The application and database are in fact the heart of the issue as so many of us still have systems managing customer data in a casual manner. Unencrypted or unmasked PAN’s are absolutely not allowed. In fact if you have to have them in your system, try and keep them in memory and ensure you flush them clear when the authorization has been made, or if you cannot help but have them in your database make sure you either encrypt the database or mask the PAN, some say you can leave the first 6 and last 4 numbers visible, but for my own systems we mask all the numbers in a PAN except for the last four. Our advantage with our e-commerce payment processor system is that we wrote it from the ground up so the customer service and administration modules work perfectly well with only the last four digits being visible. You may have issues with this, but you must at least try to mask the minimum leaving only the first 6 and last 4 digits visible. The entire aim of the work you need to do here is to protect all cardholder data, making nothing visible within the database that will expose the PAN, the end date or the security code. By the way, you cannot retain the security code anywhere in your database or application, and if you do use it in memory for authorization purposes, flush it directly after sending it on to the bank or network you link up with (obviously ensure the integrity of the message sent first).
There is obviously more to this whole process, but it was not my intention to detail everything you will need to do, more just giving you an indication as to what you will need to do. PCI DSS sounds impossible to achieve when you first get involved, but breaking it down into smaller components makes a lot of sense and gets you motivated into thinking the impossible may just be possible. If you wrote your own systems, you will need to do things like prove the processes and techniques used to write software at your firm. There are some good references for this on the Internet too, so I won’t waste too much time discussing that. Now, this is the highest priority for you to do in all of the above tasks, write your processes and procedures down, lock them into a system of sorts if you wish (See my post on AdventNet ManageEngine ServiceDesk Plus for $1600 well spent). As with all certifications of processes and systems, showing that you have a set of written procedures for all the tasks in your company is the MOST important part of PCI DSS. You cannot go into PCI DSS without a proper set of documents detailing your processes and procedures. For example, do you track changes within your company (change requests, and resulting management there of)? Do you capture security issues for anything within your company and detail exactly what they were and how you managed to fix them? Do you have a security officer within the company managing all these issues for you? Do your IT staff, software engineers, network support, customer service personnel know their roles, restrictions, limitations, access rights and so on regarding customer information, card data, cardholder information and so on? It can even be as simple as asking whether you shred sensitive documents and so on and so on.
I can write a book about this, but essentially what I am trying to show about PCI DSS certification is that you can pass it if you approach it logically and with security as your primary focus. Best of luck with your own audits, but if you want to know my recommendation for a QSA then give the O-C Group a try. They are a team of engineers that will walk alongside you to complete your compliance!
New Ideas Consulting 