Safeguarding your system from programmers

We hear a lot about consumer fraud and the need for banks to do more to protect sensitive customer data. But a recent Celent report, issued before the Goldman Sachs theft-of-code scandal broke, noted that while consumer fraud is extremely important, "its effects pale in comparison to the consequences of internal fraud. Employees and insiders have the potential to devastate a bank--ruin its business, trash its reputation, swindle the bank and its customers, and demoralize employees."

We've seen this in various forms over and over again. Usually, it takes the form of a rogue trader. Most banks have taken steps to safeguard their trading facilities. But the Goldman Sachs code controversy reveals a new area of vulnerability that banks ought to take very seriously.

What are the chances a departing programmer left with proprietary code in some form? The chance may be higher than we think. Some think that Goldman Sachs dropped the ball. To the extent that it allowed someone to siphon off code, that's true. But one could also argue its system flagged the anomaly, which prompted it to take action. It's going to be very hard to deny a programmer who really wants the code.  

For more:
- here's look at the Celent report

Related Articles:
Details on Goldman Scandal emerge
So, what should Goldman Sachs do?
Software programmer steals from Goldman Sachs?
Citadel sues former employees