Comments on: $7.1 billion loss at major European Bank due to fraud http://cubist.cs.washington.edu/Security/2008/01/24/71-billion-loss-at-major-european-bank-due-to-fraud/ Wed, 20 Aug 2008 16:56:59 +0000 http://wordpress.org/?v=2.5.1 By: Karen http://cubist.cs.washington.edu/Security/2008/01/24/71-billion-loss-at-major-european-bank-due-to-fraud/#comment-4071 Karen Tue, 18 Mar 2008 09:01:12 +0000 http://cubist.cs.washington.edu/Security/2008/01/24/71-billion-loss-at-major-european-bank-due-to-fraud/#comment-4071 fraud is very alarming.. We must be aware of this. Tanks for sharing this. More power! fraud is very alarming.. We must be aware of this. Tanks for sharing this. More power!

]]> By: chrt00 http://cubist.cs.washington.edu/Security/2008/01/24/71-billion-loss-at-major-european-bank-due-to-fraud/#comment-131 chrt00 Mon, 28 Jan 2008 06:09:52 +0000 http://cubist.cs.washington.edu/Security/2008/01/24/71-billion-loss-at-major-european-bank-due-to-fraud/#comment-131 It seems banks traditionally are concerned about being discrete with situations with fraud to reduce damage to company reputation. However with the advent of computer based systems, and the volume of transactions, an audit can take a long time before an intrusion or damage has been done. It seems banks traditionally are concerned about being discrete with situations with fraud to reduce damage to company reputation. However with the advent of computer based systems, and the volume of transactions, an audit can take a long time before an intrusion or damage has been done.

]]> By: mccoyt http://cubist.cs.washington.edu/Security/2008/01/24/71-billion-loss-at-major-european-bank-due-to-fraud/#comment-128 mccoyt Mon, 28 Jan 2008 05:57:51 +0000 http://cubist.cs.washington.edu/Security/2008/01/24/71-billion-loss-at-major-european-bank-due-to-fraud/#comment-128 This story is a great illustration of some of the more interesting aspects of the Trusted Computing Base concept that we've discussed in the last week. While one view of the model revolves around the trusted execution and manipulation of code, that paradigm can be extended to take into account more than just code on a machine. Indeed, it can include the entire user base and network environment of a computer system. The question of who to trust then becomes substantially more difficult to answer. In the case of this story, we see an example where a trusted element of Société Générale's system clearly had more priviledge access than should have ever been allowed. As the International Herald Tribune reports in the links above, the risk management division of the company is still trying to figure out how Kerviel managed to gain access to the billions of dollars he misappropriated. Based on the initial reports, it sounds like the actions Keviel took were made possible by his somewhat unique position in the company as both a trader and a knowledgeable systems architect. Yet this incident cannot be treated as an edge case to be dismissed as anectdotal. One could argue that it is indicative of a common failure that companies make in determining who should be trusted, and to what degree. For years the commecial sector has been aware of the security threats facing it from outside the corporate firewall, but many forget to protect themselves from the potential of an insider threat within the company. Société Générale noted that Keviel broke through five seperate layers of security to carry-out his trades. Clearly, those layers of security were directed outward, and not toward those with inside access or significant knowledge of the system. This doesn't seem like a particularly surprising result when you consider that Keviel was likely considered by the security infrastructure at SocGen as trustworthy. Indeed, it sounds as though he needed such deep access to perform his job. The matter of trust, then, cannot be thought of as black and white, trusted or not. Instead, a concept of degrees of trust might have served SocGen far better. Even those who are trusted must be audited, and those with full access to one system should not have it on another. By approaching security in that way, no one person gains sufficient access to undertake such a huge degree of criminal activity without being detected. It would seem there is a lot to learn from Société Générale's mistakes. We can only hope that other institutions will consider the $7 billion price tag and take heed before they have similar problems. This story is a great illustration of some of the more interesting aspects of the Trusted Computing Base concept that we’ve discussed in the last week. While one view of the model revolves around the trusted execution and manipulation of code, that paradigm can be extended to take into account more than just code on a machine. Indeed, it can include the entire user base and network environment of a computer system. The question of who to trust then becomes substantially more difficult to answer.

In the case of this story, we see an example where a trusted element of Société Générale’s system clearly had more priviledge access than should have ever been allowed. As the International Herald Tribune reports in the links above, the risk management division of the company is still trying to figure out how Kerviel managed to gain access to the billions of dollars he misappropriated.

Based on the initial reports, it sounds like the actions Keviel took were made possible by his somewhat unique position in the company as both a trader and a knowledgeable systems architect. Yet this incident cannot be treated as an edge case to be dismissed as anectdotal. One could argue that it is indicative of a common failure that companies make in determining who should be trusted, and to what degree. For years the commecial sector has been aware of the security threats facing it from outside the corporate firewall, but many forget to protect themselves from the potential of an insider threat within the company. Société Générale noted that Keviel broke through five seperate layers of security to carry-out his trades. Clearly, those layers of security were directed outward, and not toward those with inside access or significant knowledge of the system.

This doesn’t seem like a particularly surprising result when you consider that Keviel was likely considered by the security infrastructure at SocGen as trustworthy. Indeed, it sounds as though he needed such deep access to perform his job. The matter of trust, then, cannot be thought of as black and white, trusted or not. Instead, a concept of degrees of trust might have served SocGen far better. Even those who are trusted must be audited, and those with full access to one system should not have it on another. By approaching security in that way, no one person gains sufficient access to undertake such a huge degree of criminal activity without being detected.

It would seem there is a lot to learn from Société Générale’s mistakes. We can only hope that other institutions will consider the $7 billion price tag and take heed before they have similar problems.

]]>