Goldman Sachs hack: leak detection vs. leak prevention
Posted by Paul Roberts on July 7th, 2009 under Anti Data Leakage, Breaches, Penetration Testing, Policy Enforcement, Port and Device Control, e-crime, legal stuff.
The New York Times ran with an interesting story today on the theft of some critical IP and source code from investment bank…err…bank holding company Goldman Sachs that underscores both the value and shortcomings of data leak detection software. The article, by Graham Bowley, discloses the case of one Sergey Aleynikov, a well compensated ($400k/year), 39 year-old computer programmer who worked as Goldman’s vice president for equity strategy. Aleynikov had recently given notice and said he was joining another trading firm that would pay him triple the salary he earned at Goldman.
However “just before he left, according to the complaint, Mr. Aleynikov used his desktop computer at Goldman’s New York offices to upload a stream of code to a Web site hosted by a server based in Germany,” NYT reports. That data was later copied back to his laptop and what’s described as a “memory device.”
Goldman, it was reported, “noticed the surge of data leaving its servers,” but presumably was unable to block the transfer to the remote server.That turns out to be a big problem, as the code stolen was for so called “black box” computer programs that “Goldman uses to make lucrative, rapid-fire trades in the financial markets.” Those programs earn the firm millions a year, reportedly. And, though authorities have Aleynikov in their custody, the IP he stole is still sitting on the hosted Wed server where he deposited it, NYT reports.
While its not clear what products were responsible for picking up the theft and monitoring the data flows, the incident is a great example of the gulf that exists between the marketing buzz around DLP - or data leak prevention - technology and the reality, even at top tier firms like Goldman Sachs. Presumably that firm has the pick of the litter of security technologies, the bankroll to purchase and deploy what they want and top tier IT staff to manage the products. The fact that Goldman appears not to have had a means of blocking the transmission outside its firewall of source code and proprietary algorithms whose value is described as “incalculable” is…shall we say…eye opening.
To be sure: securing source code presents a unique challenge to DLP firms, which have tended to focus on data that might be used in identity theft or for other compromises — credit card and social security numbers, account numbers, names and so on. Today, content monitoring solutions often allow simple regular expression matching that could, in a ham fisted kind of way, be used to identify source code. Many Web filtering firms have or are adding support for features to identify source code files. At a deeper level, firms like Symantec/Vontu claim to be able to index document content (including source code files) then spot even snippets of protected content in transit. With roots in encryption, vendors like BitArmor go a step further: offering data level tagging — essentially metadata containers that travel with data, classifying it and specifying access rights, security policy (encryption) and so on. But tagging and encrypting the incredible diversity of code that resides inside an organization like Goldman Sachs is a Herculean task. And, as Mr. Aleynikov’s alleged excuse for the data breach (that he was merely trying to copy open source code he’d worked on) there are circumnstances under which the movement of source code files back and forth across the network perimeter might be allowed and desirable. On the other side of the fence, there are application protection firms like Arxan, Metaforic and VI Labs, which do a better job securing the underlying code, but have traditionally focused on blocking attempts to reverse engineer applications for piracy or industrial espionage, not spotting or blocking data flows. Finally, source code analysis outfits like Fortify and Ounce Labs, Core Security, Veracode and others focus on finding security holes in compiled or uncompiled code that might be exploited in attacks after applications are deployed.
Expect to see some of these areas of focus converging as more and more of an organization’s value comes to rest in the intellectual property locked up in internal applications and business processes. As we noted in a recent report on BitArmor, the advent of virtualization, private clouds and cloud-based services within the enterprise (as evidenced here in the unnamed hosted Web server the GS application code as spirited off to) challenge network-based DLP with a different set of requirements. Among them: monitoring data movements from local to cloud, cloud to coud or guest OS to guest OS.
Comments
Pingback from Radar Trend » Plausible Deniability » Goldman Sachs hack: leak detection vs …
Time: 7 July 2009, 5:55 pm
[...] See the rest here: Plausible Deniability » Goldman Sachs hack: leak detection vs … [...]
Comment from Yossi
Time: 9 July 2009, 9:20 am
I have come to learn most are ignorant about current day capabilities of DLP (Data Leak Prevention) technologies. I know one company claims 100% detection with no false alerts (gttb.com) and there are probably more out there.
Comment from Vic DeMarines
Time: 10 July 2009, 11:52 am
It is interesting that the individual was able to upload code via an internal network to a external server. WAF should be able to detect this type of transfer. If you cannot block this level of access, then the company stands to lose a lot more. From my piracy experience, file upload sites like Rapidshare and 100’s of others make it incredibly easy to update GB of data and make it difficult remove once there
Write a comment