Skip to content


The Central Bank Heist & COBIT 5 for Risk Management

forblogAs well as making and implementing policy, central banks run various payment and settlement systems. The flow of funds include central bank money, the nation’s foreign exchange reserves, commercial bank transactions and government payments. This amounts to billions of dollars every day. A hack on a central bank is unthinkable because it is disastrous for the nation.

February 2016 saw the unthinkable happen. The largest known hack on a central bank, in this case the Central Bank of Bangladesh, took place. $81 million dollars were stolen – it could have been far worse as the attempt was for $951 million – but for one of the poorest counties in the world, it was still very, very bad.

This blog looks at the key things that went wrong at the central bank and how COBIT 5 risk guidance might have helped identify the threats before they were exploited. The benefit of hindsight is that the threats are easier to spot. Although hindsight cannot prevent what has happened we can all learn from it.

So, what contributed to the successful theft of $81 million?*
1. The central bank was unable to open the SWIFT financial system, the system used for secure payments by all the major banks in the world.
2. The printer, that reported transactions and exceptions, once again was not working. No-one was able to see the error messages “a file is missing or changed”.
3. Multiple countries in different time zones were involved – USA, Sri Lanka, Philippines and Bangladesh.
4. The differences in Muslim (Friday and Saturday) and Christian (Saturday and Sunday) weekends.
5. The Chinese New Year is a holiday in the Philippines.
6. Malware in the CB’s computer systems.
7. Philippines gambling laws had been loosened as the Chinese tightened theirs, causing a drift to the Philippines.
8. Poor execution of anti-money laundering policies in the Philippines and Bangladesh.
9. Gaping holes in legislation.
10. The Bangladeshi Sovereign account was insecure.
11. Multiple parties were involved: SWIFT, New York Fed, Deutsche Bank, Rizal Commercial Banking Corporation to name a few.

As a result:

  • It was unclear for some time how much money went out.
  • It was not possible to identify where some of the orders came from.
  • It was difficult to communicate across different weekends and holidays.

BUT

  • Luck prevented all orders going through: a spelling mistake in a beneficiary’s name was spotted so that the bulk of the transactions were halted.
  •  The Bangladesh’s central bank governor resigned.

Other considerations:

  • A developing nation is unlikely to invest as much in its IT security as richer countries.
  • Scarce and costly IT personnel make it difficult for developing nations to attract talent.
  • Work culture, motivation and reward practices and ethical norms can prevent people sticking the head above the parapet.

It looks like a ‘perfect storm’, ripe for exploitation but could this particular heist have been prevented? The answer is yes. Can COBIT 5’s Risk guidance help make sense of the potential impact of many different risks? Yes it can. This is how.

ISACA’s “COBIT 5 for Risk”, a part of the COBIT 5 family, sets out how to assess risk against the COBIT 5 principles. The focus is on the bigger picture, context, and cause and effect of exploiting single and multiple vulnerabilities. In summary:

  • Meeting stakeholders’ needs would have led to assessing risks in end-to-end payment and settlement transactions for customers, multiple 3rd parties and differing jurisdictions. It would have identified that differing weekends and holidays need to be managed in case of queries or incidents. (3, 4, 5, 11 above)
  • Covering the enterprise end-to-end would have identified critical resources that needed to be on hand and working 24 X 7, such as the printer and escalation procedures. (1, 2, 6, 10)
  • Applying a single, integrated framework would have meant working with partners better to better identify and react to queries and incidents.(3, 4, 5, 11)
  • Enabling a holistic approach would allow for a managed approach to local and international differences. (7, 8, 9)
  • Separating governance from management would mean that local managers would have the authority to assess and control risks so that sufficiently robust and tested ‘preventative’, detective’ and ‘corrective’ practices were in place and available when required. (1, 2, 6, 8, 9, 10).

In summary, COBIT 5’s approach to risk management is not just about IT or just about business policies and practices, it is about the whole enterprise and the whole process. That means all aspects of any function, whether internal to an organisation or crossing organisations and countries, are fully assessed in the context for which they were created, including people and culture.

Of course the blog simplifies a very complex, continuous and time-consuming set of activities, but doing these is still cheaper than the financial, reputational and personal loss this heist has caused. I am very happy to do a review for you just for a couple of million dollars. Cheap at the price!

My next blog will look at how COBIT 5’s security guidance could have helped control some of the risks.

Sue Milton

 

If you would like more information on COBIT 5 please refer to https://apmg-cyber.com/products/cobit5.

Sources: Articles via www.ft.com; Wikipedia, and InfoSecurity Magazine.

Posted in COBIT 5, Cyber Security.

Tagged with .