Can Architects Stop Financial Ruin and Market Meltdowns?

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

Community

Architecture

Topics

Security ,

Leadership ,

Stories & Case Studies ,

Legal Matters

Tags

Business Architecture ,

Best Practices

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:
• The landmark book Security Engineering: A Guide to Building Dependable Distributed Systems
  
• Relevant Enterprise Risk Management industry frameworks such as COSO and RIMS.
• The Information Technology Infrastructure Library
• 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.

• Older >