Plausible Deniability

One of the lingering questions behind the massive theft of data at retailers like Hannaford Supermarkets and TJX Corp. in recent years has been the source of the malicious software used to carry out those attacks. Much is now known about the scope of hacks like the theft of data on more than 45 million credit and debit card accounts used at TJX-owned stores between 2005 and 2007.

We know roughly how much data was taken, and a timeline of when the company became aware of it. We can guess at the sophistication of the attack by noting, for example, that almost 18 months passed between the initial compromise and the company learning that its network had been compromised. However, details in the press are often lacking. We hear that “malicious software” was used, that it stole data in transit, or from a database and stored it in files that were later transferred off the network.

What’s missing is the provenance of the malware itself — was it a variant of a common, information stealing program like Torpig, or a custom application developed specifically for the attack in question? The answer to those types of question suggests a lot about the amount of effort and investment that preceded an attack — was it merely a target of opportunity, caught up in the net cast by a massive spam run, or did the criminals in question have their sites set on the victim from the outset?

With arrests in some of these cases, those with knowledge of them are now beginning to flip in an effort to avoid harsh sentences. That, in turn, is leading to more arrests and more details about the eye-popping data breaches that have dominated headlines. Those details are reason for concern, particularly for high profile companies that might be worried about the threat posed by rogue insiders and targeted attacks.

Take the case of Stephen Watt, the New York man who was named in an indictment filed in U.S. District Court in Massachusetts on October 29. According to some published reports, Watt was part of a criminal ring that engaged in wire fraud, identity theft, money laundering and unlawful access to computers — all part of a scheme to steal more than 45 million credit and debit card account numbers from TJX, authoring the sniffer program used to steal the credit card information. That program, dubbed “blabla” was apparently written and then repeatedly modified by Watt for Albert Gonzalez, a co-conspirator who is believed to be the mastermind of the TJX scheme. Gonzalez, otherwise known as “Segvec,” was acting as a federal informant at the time he was also engaged in pilfering data from TJX.

Watt hasn’t been convicted of anything yet. Moreover, not much is known about the government’s case against him. It’s entirely possible that he developed the blabla application in a vacuum and with penetration testing, rather than data exfiltration in mind,–completely ignorant of Gonzalez’s larger plan. Time will tell.

What is clear is that Watt was a talented developer and security mind with the resume to match. His LinkedIn profile shows him working currently for Imagine Software Inc., a company that makes trading system software used by “hedge funds, pension funds, investment banks, brokerages, and sovereign wealth funds.” His LinkedIn profile claims stints at financial services giant Morgan Stanley, where he worked on “Application infrastructure development and inhouse security toolkit development.” It also claims he worked at SaaS based vulnerability scanning firm Qualys where he says he “conducted research and development for an industry-leading network vulnerability scanner..and developed proof-of-concept exploits for discovered vulnerabilities,” among other things.

UPDATE: Qualys says the LinkedIn information is inaccurate. According to company HR records, Watt worked as a summer intern for two summers, in 2001 and 2002, where he helped test that company’s scan engine. He never conducted research and development for Qualys, according to the company.

His work for Morgan and Imagine overlaps with the period of the TJX hack and his alleged work on blabla. Troubling.

The questions for security-conscious organizations of all stripes are obvious:

1) Given that you can’t stop a determined hacker from gaining access to your network, what is the proper means of protection from a hacking outfit that’s employing a top-notch developer to write custom malware just for you? 18 months between compromise and detection doesn’t sound so outrageous if TJX (and the layered defenses it employed) were just looking for stuff that looked like other stuff that was out there. They weren’t going to find Watt’s “blabla,” because nobody had ever seen blabla before. Forget that Watt was allegedly providing regular updates to the software as the hack was in progress, as is alleged in the indictment.

2) Given the hunger for IT development talent, and the unfathomable and largely anonymous world of malicious and recreational hackers, how can firms trust that their star new developer isn’t donning a black hat when he’s at the office — or even when he gets back home? This is ultimately an HR question, but its unlikely that most employers are doing the kind of “three letter agency” caliber due diligence on IT staff that would uproot questionable associations like Watt’s.

Surveys of end users that we’ve conducted show acute interest in anti fraud technology that can provide intelligence about threats posed by insiders regardless of seniority, from the low-level call-center agent and receptionist, up through senior managers. Firms like call center giant NICE have already invested in this space, marrying anti-fraud to their existing monitoring platforms.

Companies like Guardian Analytics have come out with software that they claim can analyze and model user behaviors to spot weirdness that might indicate an account takeover or compromise. But most of these products are focused on transaction-based security - fraud and money laundering. Watt poses an even hairier problem: what posture do you take towards your realtime trading system software — say — once you realize that one of your developers was donning a black hat — at least some of the time? Better yet, what internal controls can you institute that will help connect the dots leading to a questionable developer. Is it merely a matter of hiring nosey managers and smart QA people, or is some extra layer of scrutiny needed? All of this assumes, of course, that there was some bleed over between white hat and black hat. That may not be the case every time. But as word of this indictment spreads, I wouldn’t be surprised to hear that there are some heated conversations and hastily arranged audits to assess the collateral damage — if any.