PCI Compliance – The Good, The Bad, and The Insecure – Part 2
In this second part of the compliance article, the author explains in detail how each and every category in the PCI DSS requirements should be dealt with to ensure that your websites, web applications and also business are operating securely. This is the definitive guide to PCI DSS compliance every business and organization should read.
Your Information will be kept private.
Stay up to date on web security trends
Your Information will be kept private.
If Compliance is Not Enough, What Else is Needed to Secure Web Applications?As we have seen in part 1 of PCI Complaince, the Good, the Bad and the Insecure, PCI compliance is a good idea in abstract, however it should be viewed only as a starting point, given its rather minimalistic and generic approach to meeting compliance requirements. One of the largest problems with PCI compliance is the absolute lack of real, technical requirements. For example, the very first requirement is to have a firewall designed to protect cardholder data. That sounds good on paper, but nothing actually says how or to what degree this firewall must protect data. Consider that any random Joe McSysadmin can throw a firewall on their network and call themselves compliant, and they would be technically correct. But that would not actually protect their network and web applications in any realistic way unless that firewall was finely and appropriately tuned, which is not thoroughly detailed in any real way under the PCI guidelines. Indeed, most merchants find themselves meeting the requirements at the most basic and minimal levels necessary, which properly explains the annual amount of cardholder data that gets compromised. Instead, merchants should go well above and beyond the basic and often ambiguous generalities of PCI compliance requirements. As mentioned earlier, there are six categories of PCI compliance, each with a subset of rules. The following details a good starting point and some additional steps all merchants should follow when attempting to become PCI compliant:
A Complete Guide to Having PCI Compliant Web Applications and Business
Build and Maintain a Secure Network1. Install and maintain a firewall configuration to protect cardholder data: Just installing and configuring a basic firewall is not enough, even if it meets the PCI requirements. It is also imperative that all externally-facing systems (and, indeed, even some internal-only systems as well) not only be properly configured with adaptive and well-tuned firewalls, but that the firewall logs be frequently inspected as well. And by adaptive, this means that the firewall should both automatically and manually improve itself actively with traffic that occurs, including but not limited to rate-limiting or outright blocking questionable traffic, and alerting security engineers of any possible trouble. This is not only to prevent external threats from gaining entry, but also to prevent even insider threats from gaining access they should not have (hence the prior mention of internal-only systems). This also is not limited to your web servers, but any systems on your network as well, such as your employees' desktop computers. In 2011, RSA Security - an American computer and network security organization used in both high-level corporate business and government contracting - fell victim to a social engineering and trojan horse attack that rendered their SecurID two-factor authentication tokens useless, all due to a compromised employee desktop from a simple infected email attachment. For more information about this attack click here. Most insider threats are not intentionally committed by disgruntled employees, but in fact occur from poor computing practices on insecure networks. 2. Do not use vendor-supplied defaults for system passwords and other security parameters: Time and time again, network engineers install routers with cisco:cisco username/password combinations, thinking, "Surely, no one will make it in this far." Wrong. The same can be said for practically anything that comes supplied with defaults, be they passwords or configurations. There exists plenty of black-hat scanners that search for fresh installations of WordPress, phpMyAdmin, and various other easy-access web applications and software for that brief period just after installation when default passwords have not yet been changed. Just this momentary exposure can wreck havoc on an administrator's setup, or even the whole network. It is also worth mention that this requirement should include any defaults, including configuration, such as ports and version replies. There exists no reason to leave SSH port 22 open to the world unless you are running a shell server, in which case that shell server should never be even the slightest bit connected to cardholder data to begin with. There also exists no reason to leave the full version reply in the Apache web server reply headers. In fact, wherever possible, the most minimal information should be supplied, or none at all if it is not critically necessary. The less potential attackers can glean from your surroundings, and the less entry points made available to them, the more secure your systems will be.
Protect Cardholder Data3. Protect stored cardholder data: This requirement should go without saying, but often gets ignored or mostly overlooked once the first requirement is completed. For example: With PCI compliance, it is required that CVV numbers not be stored whatsoever, and that cardholder data such as the card number, ZIP code, and cardholder name all be stored in an encrypted format. All too often, neither of these two requirements are completed. Some eCart software provides this functionality already, but also does an ineffective job of protecting the keys used in the encryption/decryption process. What good is a lock if you leave the keys in it? This sort of mass-compromise is easy preventable by two simple methods of data protection:
- One-Way Encryption: It is not necessary to store cardholder or personally identifiable information in a decryptable method unless absolutely necessary, such as recurring charge payments or saving cardholder data for future easy payment methods. If you absolutely must store cardholder data for whatever reason, and have no reasonable need to retrieve it later, then encrypt it using a highly secure one-way algorithm, such as salted SHA512.
- Store Keys Offsite: If you absolutely must store cardholder data and have reasonable need to retrieve it later, then keep your encryption methods offsite (or, if multiple servers are infeasible, inaccessible to the publicly-facing services, such as by process chroot and permissions). One way you can do this is by running a service on a system that is inaccessible from your publicly-facing servers or services (e.g. via SSH or NFS for separate systems; open permissions shared processes; or any other access methods) that takes only two actions: Receive cardholder data to encrypt and store, or charge existing stored cardholder data with a defined cost (such a command could be like: charge client #123 with $29.95 USD to their payment method #2). This service would never return cardholder or personally identifiable data via any query, thus preventing that data from ever being compromised. This service could be coupled with exclusive access to your cardholder database as well for simplicity, just so long as - again - it does not return any privileged data.
Maintain a Vulnerability Management Program5. Use and regularly update anti-virus software: As stated all the way back in Requirement #1 (Install and maintain a firewall configuration to protect cardholder data), protection of your externally-facing systems is a highly important duty to maintain. Also as previously stated, your employees' terminals are very important in this field of protection as well. However, a piece of software is only as good as the user running it. Included in this requirement should also be highly effective education of good computing practices, as well. In the aforementioned 2011 RSA Security hack, ineffective anti-virus and firewall software coupled with poor computing practices of opening unsafe email attachments both ultimately led to the $66 million USD loss RSA Security felt as a result. 6. Develop and maintain secure systems and applications: Probably one of the most important requirements of PCI compliance, this requirement acts as a sort of umbrella over other requirements to re-assert the absolute and unarguably significant importance of security and web application security. As mentioned in Requirements #1, #5, later in #9, and several others, security is of the utmost importance with regard to cardholder data -- this cannot be over-stressed. Good firewalls, anti-virus services and frequent web application security scans; Encryption when crossing public channels; Encrypted storage of cardholder data, authentication tokens and passcodes (perhaps even methodology of two-factor authentication or biometrics). Additionally, later, in Requirement #10, we will address detailed and secured logging of all privileged activity. These all and more, you may notice, are repetitiously repeated in recurring repetition, repeatedly. Why? Because if they were not some of the most problematic failures of PCI compliance, there would exist no reason to continually drive these points home.
Implement Strong Access Control Measures7. Restrict access to cardholder data by business need-to-know: As with the next requirement, #8, access restrictions are a highly crucial element of protecting cardholder data, namely with regards to privileged personnel. However, unfortunately this requirement is often overlooked at a service level. In the technology industry, there exists a principle known as Least Privilege. As its name implies, the concept involves granting a service or user the least amount of privileges necessary to complete their job, including the revocation of temporary privileges applied where necessary. This principle should not be foreign to our readers, as we have previously discussed this concept several times already, and for good reason. Indeed, as discussed in our SQL injection articles, the restriction of permissions to the most minimalist level required is quite the common concept; As Linux administrators, for example, we apply this methodology to stored data in the form of filesystem permissions. So, too, should this concept be applied wherever possible, especially in environments that handle sensitive information such as cardholder data. In Requirement #3, we exemplified the scenario of a web forum coupled with an eCart for premium access. In that scenario, the principles of Separation of Privileges and Segregation of Data are further deeply enhanced by the principle of Least Privilege when applied to database permissions. Of course, Least Privilege is not exclusive to database permissions, either. The concept is appropriately applied to everything that has any level of access, such as on-disk stored data, backups, employee file stores, communication pathways, command and control systems, even the contents of the access control lists themselves (it is unwise to tell an intruder what they must infiltrate next in order to gain the desired escalated privileges). In any and every possible area, Least Privilege should be applied and strictly enforced to minimalize the damage and effectiveness of when -- not if -- a hacker ultimately gains access to a service. 8. Assign a unique ID to each person with computer access: This may seem like a relatively simple requirement, but it actually has quite a few layers of complexity beyond the obvious. As mentioned in Requirement #5, good education of computing practices should also be mandated with anyone who may have privileged access to sensitive data, but there are indeed other important aspects. For example, what good is a unique ID if the systems utilizing those authentication methods are insecure? By 'insecure', this does not only mean the insecurity of the network nor a poor anti-virus posture, but rather this also very importantly includes the computing practices of the users of those unique ID logins as well. As mentioned in Requirement #6, all systems involved, including those requiring unique ID authentication, should be secure. Equally important, though, are the security practices of the possessors of those unique ID authenticators. This can include many things, such as a strong understanding of social engineering approaches, how to employ safe computing, reduction of high-risk exposure on social networking or other arenas, and so forth. Again, proper education of secure computing practices cannot go far enough. Also, as mentioned in the prior requirement, #7, this requirement does not exclusively apply to actual personnel, but services as well. Along with the principle of Least Privilege, services should possess unique access exclusive to each service unless the sharing of access is absolutely necessary (which should be avoided via protected communication pathways wherever possible). You can consider this another way: If a user can cause damage by sharing his or her credentials, so too can a service exploited by a hacker when its access is shared among other services. 9. Restrict physical access to cardholder data: Indeed, for some merchants this requirement may exceed their ability to control, especially in the cases of an online store. However, simply using a reliable and trustworthy hosting provider would adequately meet the compliance necessities for this requirement. This also does include ensuring that the server hosting your online shopping system is exclusively accessible only by you or other users properly privileged by Requirement #8 above, such as by avoiding shared hosting (a topic we have addressed previously) or other methods that would give unauthorized users privileged access (such as through a hypervisor terminal with VPS hosting). And, of course, physical security does obviously include the systems you and other privileged users have physical access to, both permanently installed or otherwise. Over the past several years, major corporations and, indeed, even the United States federal government itself have all fallen victim to massive security breaches due to failed physical security, most often due to unsecured laptops illogically carrying enormous troves of highly sensitive personally identifiable information. Ignoring the absolute irrational absurdity of laptops carrying vast amounts of highly sensitive, the lack of simple hard drive encryption led to several tens of millions of peoples' private information being leaked to entities that had no business accessing that data (resulting in billions of dollars of loss, via both identity theft and fraud or lawsuits).
Regularly Monitor and Test Networks10. Track and monitor all access to network resources and cardholder data: Not just with merchant systems that handle cardholder data, but practically every type of server imaginable, this often gets overlooked as needlessly unimportant, when in fact it is an extremely valuable asset. First, look at the side of monitoring, namely for its value in uptime, but also for its usefulness with security and rapid response. It is unreasonable and impossible to manually check on services constantly to ensure their consistent uptime and reliability. Many tools exist -- Nagios and Icinga are two of the most popular, among many others -- that allow you to monitor any conceivable service. Furthermore, most all monitoring software are incredibly simple to setup, requiring only the knowledge of the services you wish to monitor. For example, with the aforementioned Nagios and Icinga, system checks are performed via a series of check scripts or utilities. Nagios and Icinga require only two things from these check scripts: an exit code (0 for OK, 1 for Warning, 2 for Critical, 3 for Unknown) and a single line of status text. That really is all that is required. And you can generate a check script for practically anything -- CPU and memory utilization, properly formatted website output, TCP service replies, even monitoring the local weather around your remote data centers. Anything and everything can be monitored and give you not only the visibility of the moment any problem occurs, but also the moment any security issue erupts. That brings us to the second side of this: Logging. Sometimes real-time monitoring of your systems and services may not prove completely effective. Sure, they keep you appraised of your uptime and general responsiveness, but a monitor is only as good as the things it monitors. It cannot watch for what it does not know to watch for. While you may be capable of finding when most kinds of attacks occur, as they occur, you may not be able to see them all. Thus, it is imperative to have a reliable, offsite monitoring system. Why did we heavily underscore the word 'offsite'? Well, we would not highlight something we felt no need to stress the importance of, now would we? Think of it this way: A convenience store has security cameras, and a system that records the images captured by those cameras. Would you leave those recording devices behind the counter, beside the register a robber is stealing from? Of course not. So why would you leave the records of an attacker's intrusion on the very server they are intruding upon? There exist many solutions, both free and corporate, that allow users to store logging in an offsite format. The two simplest are a Syslog variant, and a dedicated offsite monitoring agent. By default, most Linux and Unix varieties have their own form of Syslog already operating locally. To facilitate the storage of offsite logging engines, administrators can use either syslog-ng (which often comes standard on modern distributions of Linux), or rsyslog, both of which can be interchangeable with some similar-but-different functionality. A far better solution, however, is an offsite monitoring agent, such as the open-source OSSEC -- a host-based intrusion detection system that can perform offsite logging, among many other features, even including this very requirement of PCI compliance. 11. Regularly test security systems and processes: This requirement proves to create a rather tricky problem: A vulnerability scan is only as effective as the list of vulnerabilities it knows to scan for. Indeed, it is impossible to truly account for all unknowns, so the best a vulnerability scan can do is check for the conceivable known methods of intrusion. Thus, it is exceedingly necessary to take a very outside-the-box approach, where thinking abstractly like a hacker becomes a useful skill to employ. A skilled security engineer would not only run vulnerability scans, but could also even perform wargame scenarios to attempt real-world tests of all sorts of intrusion methods in order to most effectively find weaknesses and best craft successful remediation solutions. This is not just limited to checking firewalls, ensuring anti-virus scanners are up-to-date, or verifying traffic is encrypted. This includes everything and anything -- even almost absurd roleplaying tests, such as:
- Social Engineering: Real-world, unannounced tests of the personnel's ability to respond and resist being exploited as a security weakness
- Insider Threat:Testing both the damaging ramifications of a user or service's access being compromised, either accidentally or intentionally, such as in the case of a disgruntled employee
- Response and Remediation: In the event of ultimate catastrophic failure of security protocols, determine how quickly can a security team react and control the situation