PCI Compliance. What They Don't Want You To Know

All of the recent news about Target, Neiman Marcus, and other businesses being hacked might be a surprise to many but it’s no surprise to us. Truth is that practice of security has devolved into a political image focused designed satisfy technically inept regulatory requirements that do little or nothing to protect critical business assets. What’s worse is that many security companies are capitalizing on this devolution rather than providing effective solutions in the spirit of good security. This is especially true with regards to the penetration testing industry.

We all know that money is the lifeblood of business and that a failure to meet regulatory requirements threatens that lifeblood. After all, when a business is not in compliance it runs the risk of being fined or not being allowed to operate. In addition the imaginary expenses associated with true security are often perceived as a financial burden (another lifeblood threat). This is usually because the RoI of good security is only apparent when a would-be compromise is prevented. Too many business managers are of the opinion that “it won’t happen to us” until they become a target and it does. These combined ignorant views degrade the overall importance of real security and make the satisfaction of regulatory requirements the top priority. This is unfortunate given that compliance often has little to do with actual security.

Most regulatory requirements are so poorly defined they can be satisfied with the most basic solution. For example PCI-DSS requires merchants to undergo regular penetration tests and yet it completely fails to define the minimum level of threat (almost synonymous with quality) that those tests should be delivered at. This lack of clear definition gives business owners the ability to satisfy compliance with the cheapest most basic of testing services. To put this into perspective, if the standards used to test bulletproof vests (NIJ and HOSDB test methods) were replaced by PCI–DSS then bulletproof vest testing could be satisfied with a squirt gun.

These substandard regulatory requirements combined with business owners lacking in true security expertise formed a market where exceedingly low quality, low-threat, easy to deliver security-testing services are in high-demand. This market has been answered by a horde of self-proclaimed security experts that in almost all cases are little more than marginally capable script-kids and yet they inaccurately market their services as best in class. Take away their third party tools (scripts, scanners, Metasploit, etc.) and those vendors will be dead in the water. Take the tools away from a bona fide researcher or hacker and they’ll write new tools then hack you with a vengeance.

The saturation of the penetration testing industry with charlatans makes the process of identifying a quality vendor difficult for business managers that actually care about security. In many cases the consumer is a non-technical (or non-security expert) buyer and not able to truly assess the technical capabilities of the vendor. As a result they often make buy decisions based on the non-technical exploration of things like the number customers serviced, annual revenue, size of company, etc. While these are important factors when evaluating any business, they are by no means a measure of service quality and testing vendor capability. With regards to penetration testing services, quality of service is of the utmost importance and it is a highly technical matter. This is why we wrote a guide to vendor selection that sets a standard of quality and was featured on Forbes.

It is unfortunate that most business owners don’t seem to operate in spirit of good security but instead operate with revenue focused tunnel vision. The irony of this is that the cost of a quality penetration test is equal to a small fraction of the cost of a single successful compromise. For example, in 2011 Sony suffered a compromise that resulted in over 170 million dollars in damages (not including fines). This compromise was the result of the exploitation of a basic SQL Injection vulnerability in a web server (like Target). The average cost of Netragard’s web application penetration testing services in 2013 was $14,000.00 and our services would have detected the basic SQL Injection vulnerability that cost Sony so much money. Perhaps its time to rethink the value of genuine penetration testing? Clearly genuine penetration testing has a positive revenue impact through prevention. Specifically the Return on Investment of a genuine penetration test is equal to the cost in damages of a single successful compromise.

So what of Target.
We know that target was initially compromised through the exploitation of a vulnerability in one of their web servers (just like Sony and so many others). This vulnerability went unidentified for some time even after the initial malicious compromise. Why did malicious hackers find this vulnerability before Target? Why was Target unaware of their existing paths to both compromise data exfiltration? Who determined that Target was PCI compliant when PCI specifically requires environmental segregation and Target’s environment was clearly not properly segregated?

A path to compromise is the path that an attacker must take in order to access sensitive information. In the case of Target this information was cardholder data. The attackers had no issue exploiting a path to compromise and propagating their attack from their initial point of compromise to the Point of Sale terminals. The existence of the path to compromise should have resulted PCI failure, why didn’t it?

A path for data exfiltration is the method that an attacker uses to extract data from a compromised network. In the case of Target the attackers were able to extract a large amount of information before any sort of preventative response could be taken. This demonstrates that a path for data exfiltration existed and may still exist today. As with the path to compromise, the path for data exfiltration should have resulted in a PCI failure, why didn’t it?

We also know that Target’s own security monitoring capabilities were (and probably still are) terrible. Based on a Krebs on Security article, the hackers first uploaded malware to Targets points of sale. Then they configured a control server on Target’s internal network to which the malware would report cardholder data. Then the hackers would login to the control server remotely and repeatedly to download the stolen cardholder data. Why and how did target fail to detect this activity in time to prevent the incident?
If we use the little information that we have about Targets compromise as a light-weight penetration testing report we can provide some generic, high-level methods for remediation. What we’re suggesting here is hardly a complete solution (because the full details aren’t known) but it’s good advice nonetheless.

• • Deploy a web application firewall (ModSecuirty or something similar). This would address the issue of the web application compromise (in theory). If one is already deployed then it’s in need of a serious reconfiguration and whoever is charged with its monitoring and upkeep should be either trained properly or replaced (sorry). Most web application vulnerabilities are not exploited on the first try and their exploitation often generates significant noise. That noise likely went without notice in the case of Target.

• • Deploy a host-based monitoring solution on public facing servers. This would further address the issue of web server security and would help to prevent distributed metastasis. For companies that want an open source solution we’d suggest something like OSSEC with the appropriate active response configurations. For example, tuning OSSEC to monitor and react to system logs, web application firewall incidents, network intrusion incidents, etc. can be highly effective and its free. OSSEC can also be used to build blacklists of IP addresses that continually exhibit hostile behavior.

• • Deploy a network intrusion prevention solution (like snort) on the internal network at the demarcation points of the cardholder environment. If done properly this would help to block the path to compromise and path for data exfiltration. This solution should be tuned with custom rules to watch for any indication of cardholder data being transmitted out over the network. It should also be tuned to watch for anomalous connections that might be the product of rootkit’s, etc. In the event that something is detected it should respond in a way that ensures that the affected source and targets are isolated from the rest of network.

• • Deploy a second host based solution like bit9 on the Points of Sale (PoS). (No we’re not a reseller and have no affiliation with bit9). This solution should be deployed on the points of sale assuming that bit9 will run on them. This will address the issue of malware being deployed on the points of sale and being used to steal credit card information. Especially malware that was first created in 2013 (BlackPOS).

• • Hire a real Penetration Testing vendor. Given what we know about this compromise, Target hasn’t been selecting penetration testing vendors using the right criteria. Any genuine penetration testing vendor that delivers quality services at realistic levels of threat would have identified many of these issues. In fact, its fair to say that following the methods for remediation that come from a genuine penetration test would have prevented the compromise of cardholder data.