This is page 3 of:
Gonzalez: The Al Capone Of Cyber Thieves?
“PCI says that you must regularly test security systems. These hackers dodged every bullet point of PCI. A test would (and probably did) prove nothing more than PCI-test-detectable breaches would have been detected. And finally, the hackers apparently didn’t feel compelled to comply with corporate security policies. Game, set, and match: Hackers 12, PCI 0,” she said. “Yes, PCI compliance may have successfully defended Heartland against lesser attackers. But the bottom line is that Heartland could have been (and probably was) breached while being 100 percent PCI 1.1 compliant on all their points. The real observation here is that PCI DSS compliance was completely ineffective against these guys, no matter how the PCI guys spin it.”
Another security expert—and one who doesn’t mind in the slightest if we quote him by name—is Mark Rasch, the former head of the U.S. Justice Department’s high-tech crimes unit and today an attorney specializing in data security cases.
Rasch thought one of the more interesting takeways from this case is the fact that Gonzalez had served as a confidential informant to the U.S. Secret Service and, indeed, started these cyber attacks while still working for the feds. He extrapolates from that advice for IT executives looking to use cyber thieves—and supposedly former cyber thieves—to test their network security.
“One of the things about confidential informants is that, by their nature, they have knowledge of criminal activity. Most have knowledge because they were involved in criminal activity and have demonstrated that they’re really not trustworthy, particularly computer hackers who occupy a netherworld. They run the gamut from black to gray. This guy was really a dark grey and relatively untrustworthy. He was also what I would call amoral. Not immoral. He does not have a value system where he thought it wrong,” Rasch said. “What we’re going see more often is confidential informants who are doing undercover work for the FBI, hacking for the government. This is the same philosophy that teaches you why you should never hire hackers to do tests of your system. They are not trustworthy.”
Another security expert, albeit one who works for an encryption vendor, said a major concern for him was the fact that two and potentially three major retail chains have still yet to disclose data breaches from a year or more.
“Companies have a duty of care for their customers’ information that does not end at the swipe of a credit card. Some states have recognized and legislated that the loss of a customer’s personal data must be disclosed. To do anything else simply leaves that person open to more losses,” said Richard Wang, a manager with Sophos Labs US. “A culture of secrecy leads to underestimation of the problem, lack of response and therefore makes data breaches more likely in future, not less.”
“I think that the fact that we’ve gotten two years past the breach and to an indictment, and some of the retail players are still not revealed exposes the weaknesses in consumer protections and why breach disclosure laws–like in Massachusetts–get continuously watered down while they wait in legislative purgatory,” Wang said. “At issue in my mind is the conflict between the general feelgood concept of corporate and government transparency, and a sorry lack of actual accountability.”
-Marc
August 19th, 2009 at 10:21 am
The Tiger Woods of Cyber Crime. Amazing to me that after busting into Dave & Barry’s, he worked as informant for FBI on Shadowcrew thing and, after that gig, decided to go back to hacking into corp data.
August 19th, 2009 at 6:16 pm
A good post, and thanks for pointing out the potentially conflicting numbers between the indictments and press releases…very interesting to see how that works out.
I have spoken with some colleagues at 403 Labs (full disclosure: we are a QSA, PA QSA, and ASV firm) and we would take some exception to the comments of the retail security expert you quote. She begins by saying that the attack against Heartland Payment Systems came in the form of a back door and that such an attack obviated the efficacy of both firewalls and password rotation schemes. My colleagues and I would not dismiss too casually these controls. The intent of good network architecture and proper firewall policy is to limit access to the minimum necessary (e.g., default “deny all”) for business use. This is intended to include internal network segments (PCI DSS 1.2.1). Further, PCI specifies the need for both documentation and justification of open ports and services (PCI DSS 1.1.5-1.1.6). It’s not enough to use your firewall or firewalls to divide the company network from the Internet; PCI actively encourages segmentation between various internal zones and treating zones not directly involved in card data transactions as untrusted. Good network architecture and strict firewall rules that limit traffic don’t, by themselves, preclude the possibility of a back door being installed, but they certainly make it harder for the bad guy in question to do so and they limit the network-level access a back door has.
I would also challenge her point that password rotation “isn’t an effective defense, and shouldn’t be elevated to such by PCI or corporate ’security policies.’” Protecting access to user accounts, especially administrative or other critical accounts, is the core of password controls and very relevant to the attacks that led to many of the recent breaches. For example, the attacker needs first to install a back door onto the system in question. Often, these attacks require the attacker to compromise a privileged user account in order to install hostile software; strong passwords enforced by system-level controls defend against these attacks.
She argues that maintaining current anti-virus software is not an effective control because custom malware “will not be recognized as viral, especially if it performs no viral behaviors.” It’s not entirely clear what she means by viral behavior. Nonetheless, I’m not sure it’s wise to cease maintaining anti-virus software in the face of the numerous extant attacks that said software will detect, including keystroke capture malware used in compromising credit card data.
As for PCI’s security testing and security policies, PCI DSS 11.2 and 11.3 call for both automated vulnerability scans and penetration testing directed against both the external (e.g., Internet-facing) environment and the internal environment. The penetration tests are intended to simulate real attacks and skilled penetration testers are entirely capable of doing so. As such, a “PCI-test-detectable breach” is a pretty broad category that does include situations like these. It’s entirely possible that the penetration testing performed either wasn’t adequate or that the environment changed between the testing and the compromise, but to say that the PCI security testing requirements were inadequate sounds too broad. Also, remember that PCI DSS 12.1.2 specifically requires an annual risk assessment to identify and propose strategies to deal with threats and vulnerabilities. If you want to conclude, based on your risk assessment, that your organization needs end-to-end encryption, weekly penetration tests, and replacing card data with tokens, any competent assessor will agree with you wholeheartedly and help see to it that your information security practice lives up to this.
We may want to wait to learn more before making the statement “Heartland could have been (and probably was) breached while being 100 percent PCI 1.1 compliant on all their points.” Based on what I’ve noted above, we could conclude that this is not true. Organizations are obligated to comply with the PCI DSS, meaning they must meet all of the requirements all of the time. An assessor validates their compliance on (usually) an annual basis. It’s entirely possible that an organization could pull together to make things look good for the assessor and then let their controls lapse as soon as the report is finalized, but this misses the point entirely. PCI critics who regard the distinction between compliance and validation as a weakness ought to direct their criticism towards the organizations that claimed compliance but let their security controls lapse, rather than at the standard itself.
PCI DSS is not intended to be the maximum data security effort; it does not limit anyone from going above what the requirements dictate based on their own risk assessment. PCI doesn’t limit implementing additional controls like end-to-end encryption or additional security testing. On the contrary, it encourages this kind of activity.
August 20th, 2009 at 8:46 am
Editor’s Note: The retail exec quoted in the piece wanted to respond to Walt’s thoughts. Her comments:
I am not disagreeing with Walt on some of his points. He is certainly correct that PCI 6.5 does talk about protecting web-facing applications SQL injection and Heartland should have been looking for that exposure. If that’s the case, Hackers 11, PCI 1. The real question is if SQL injection was used as the original method of forcing entry, or only as the means for elevating privilege once the hackers were inside? The indictment text suggests the former, but one of the documents mentioned the xp_cmdshell exploit which suggests the latter, and that could have been outside the PCI review requirements.
I also agree that a properly firewalled and segmented network environment is an excellent defense, and is one of the best ways to limit exposure and maintain damage control. The problem there lies in the wriggle room around the word proper, and how that is interpreted by the company and the individual QSA. A processor is likely to run all their card handling systems in a single segment, but once that segment is breached at a processor the hackers have access to it all.
I did not say anti-virus software is ineffective against all attacks, only that it will always be ineffective against custom written malware. For software to behave like a virus it would have to spread itself, and there are some anti-virus products that detect that bad behavior. What is more effective than AV is a software execution policy that uses a whitelist instead of a blacklist, or a FIM product.
Regarding the argument against password rotation, I claim only that enforced rotation is an ineffective defense, not that policies enforcing strong passwords aren’t effective. Rotation is theoretically supposed to limit the damage, but hackers who gain system authority routinely install backdoors that render passwords ineffective, rotated or not. Password rotation primarily harms the users’ ability to remember them, forcing them to be written down.
Most security testing is thought of as walking a fence. The security team built the fence to keep the attackers out, so the natural test procedures focus on examining the fence. They look at the gate and make sure the lock is secured, they look at the walls and make sure there are no gaps, etc. They look for the vulnerabilities they expect to find. But hackers rarely come in over the fence. Instead they will find a new way to disguise themselves, or move the fenceposts, or send a purchase order for a new padlock for the gate, or trick the owners to bring their valuables outside the fence. As researchers learn these new tricks from successful hacks, they can and should be added to test suites, but it makes the hackers’ jobs easier to avoid detection when they know exactly what is being looked for.
I think Heartland was honestly trying to be PCI compliant – no company wants to leave themselves exposed. And PCI DSS does a great job of helping to keep the run of the mill hackers out of the environment. But as the article claims, Gonzales may be the Al Capone of cyber thieves. I don’t believe that 100% perfect PCI compliance would have stopped him.
August 20th, 2009 at 11:28 am
PCI DSS is a good set of practices for defense in depth, regardless of whether it is effective in every single case, or if it was applied perfectly.
I realize the discussion is about who did the stealing, and not what they stole, which is unfortunate. It misses the root cause of the problem, which is why the banks, retailers and processors are not using smart cards and cryptographic protocols to avoid all this handling of raw, valuable data in the first place. Get the valuables out of the retailers and processors hands, and the cyber-crooks will have nothing to steal.
Some people continually complain about the cost or the complexity or the inconvenience of securing the data properly. People like Gonzalez show why we must bite the bullet and do it anyway.
August 21st, 2009 at 12:54 pm
Let me make a point about PCI. I think we can all agree that compliance is not the same thing as security. In fact, I could make the case that PCI by its very nature assumes you *will* be breached and that your systems will be compromised. What PCI says is that when — notice I did not say “if” but “when” — your systems are breached, the cardholder data you are (foolishly?) storing won’t be compromised.
Just like compliance is not security, a breach doesn’t have to result in a data compromise.