InfoQ

News

Can Architects Stop Financial Ruin and Market Meltdowns?

Posted by Michael Bushe on Feb 19, 2008 07:19 AM

Community
Architecture
Topics
Legal Matters,
Leadership,
Stories & Case Studies,
Security
Tags
Best Practices,
Business Architecture
The purported  €4.9 billion  ($7.2 billion) fraud committed by Jerome Kerviel at Société Générale  has raised discussion worldwide about how systems at such a respected financial institution could be circumvented.

Financial institutions and other businesses must abide by laws and regulations, such as MiFID, and SOX, to reduce financial risk and create accurate accounting reports.   Businesses have internal motivations for risk management as well: fraud or theft can lead to reduced profits and even business failure.  Therefore businesses create significant investments in social and technical engineering to create internal controls to reduce risk.  The investigation of Jerome Kerviel reveals a story with an interesting interplay between social and technical matters.

As Bruce Schneier would be quick to point out, the strength of fraud protection is determined primarily by the people, not the technology.  Kerviel claims in the police report that Société Générale looked the other way since the trades he was making were highly profitable.  If this were true, there is nothing any software system could do about it.  The investigation of Jerome Kerviel reveals a story with an interesting interplay between social and technical matters.

InfoQ spoke with Jim Sheehy, CISSP, an IT security manager for a large state government agency for this article.  Sheehy states:
Don't underestimate the old-fashioned, non-technical controls that have served financial institutions well:  separation of duties, forcing employees to take vacations, dual-control systems, etc.
Some risk management software will track habits, such as detecting when people log onto which workstations or when they log in on a holiday.  Such software could have detected when Kerviel allegedly logged on under other user's accounts and may have raised alarms about Kerviel taking only four days off in 2007.  Other solutions search email and detect keystrokes looking for suspicious keywords or irregular activity, such as adjusting a forwarded email.  Kerviel allegedly manufactured emails with order requests in response to questions about the hedging of his trades. 

Surely five billion euro will not go missing through the use of a few spoofed emails.  All financial institutions have reconciliation procedures, where assets in each account are confirmed by another source.  Robert Annett points out that even if you are developing an online store, you should make sure the number of payments received equals the number of items sent.

Kerviel allegedly circumvented internal reconciliation checks by gaining access to databases and adjusting values to cover his trades.  Yet trading systems invariably have application and database system audit tables.  Unless Kerviel had database administrative privileges, his suspicious activity would have been logged.  Did a tree fall in the woods with no one around to hear? 

Sheehy states:
Auditing at every level of the systems (OS, database, application) is necessary, but it's only the bare beginnings. Someone/something has to parse this auditing data to make it usable, and that's where most organizations fall down. An Oracle Fine-Grained Audit log is not a pretty sight, and OS logs aren't any better. Event correlation systems that attempt to analyze and correlate audit data from disparate sources try to fill this role, but they often end up generating more false positives than anything else. This is a tough one to solve.
Indeed, the risk management industry is active, but fairly immature.  There are a number of comprehensive solutions such as BPS, Memento, Actimize, and offerings from SaS and Reuters.

Yet that may be part of the problem.  When businesses install fraud detection systems, complacency may be the result.  Some claim that workers in European finance may have put too much trust in automation because of the improved sophistication of fraud detection systems in the 10 years since the collapse of Barings Bank from a £827 million ($1.4 billion) fraud.  It is important not to let systems do the security thinking for people.  Most "white hat" security consultants will agree that in every business there are always ways someone could steal.  It is important to keep continually vigilant and creative regarding system and application security.

What can a software architect do to detect and prevent fraud?  

Sheehy comments:
In my view the most important thing a software architect can do is to think carefully about the application's business roles and map them tightly into a role-based access control system. Relying on technical barriers like firewalls, layer 7 content filtering, intrusion detection, etc. isn't enough--the developers have to build security into the application logic from the beginning of the lifecycle.
Unfortunately, the problem is becoming harder.  Software is becoming more complex and more loosely coupled.  Annett also points out that with the rise of SOA the number of entry points into the system increases, as does the security risk.  On the other hand, the decentralization of resources in SOA may make a comprehensive plot harder to implement.

Other steps architects can take to lead security improvements in their organizations:
  • Build security into the architecture from the beginning.  Security that is retrofitted is usually woefully inadequate.
  • Ensure that the appropriate auditing and reconciliation systems are in place and tested.   
  • Consider building custom event correlation systems to scan for anomalies, perhaps leveraging open source tools such as Esper.
  • Recommend and integrate strong authentication controls such as fingerprint readers.
  • Ensure system and application passwords are changed regularly.  When passwords are changed, ensure that Disaster Recovery systems are kept in sync.
  • Ensure system tests include tests of deception.
  • Secure all entry points into system.
  • Leverage resources such as:
  • Don't go it alone. 
    • Hire a white-hat to perform a security assessment.
    • Consider investments in third-party risk management and fraud detection systems and how best integrate with your applications.
Perhaps an architect alone can't thwart a multi-billion dollar fraud, but architects can help to ensure businesses maintain profits, integrity, and reputation.

No comments

Reply

Exclusive Content

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.

Security (CAS and OpenID) with Ruby

In this talk from QCon SF 2007, Justin Gehtland explains two open solutions to distributed identity and their Rails integration components: OpenID (using ruby-openid) and CAS (using rubycas-client).