Heartbleed : What banks ought to learn
I witnessed uproar across multiple forums, all concerned about how this vulnerability could be used to steal confidential data by rendering existing encryption mechanisms useless. Networking specialist firms such as Cisco Systems and Juniper Networks were forced to review their firewalls, routers, and switches to check if they were affected. Similar concerns were expressed in the banking industry by the American Bankers Association which accepted that the vulnerability was a serious threat, but added that most banks were not impacted.
So what exactly was this Heartbleed vulnerability? In simple terms it was a software bug which enabled a third party with malicious intent to steal private keys and secondary keys (like username and password) from the memory of compromised systems by exploiting a specific version of Open SSL. Open SSL is Open Source software which is used to encrypt data transmission between a server and a client using a public and private key combination. This asymmetric pair of keys prevents deciphering of content by hackers. However, if the private keys are compromised, an attacker can virtually disable this protective cover by breaking the encryption mechanism.
This bug derives its uniqueness from its long and unknown history, as well as its ability to offer a "decipher" facility to an attacker instead of the more common "eavesdropping" capability. The vulnerability is unfortunately not limited to online banking, and also impacts mobile banking. Millions of people who are using the popular Android version Jelly Bean 4.1.1 on their mobile devices are affected.
I was curious to find out how banks had reacted to this risk. While some of them were proactive in their efforts to reassure the customers regarding the safety of their data, others just reiterated that they were "not impacted by the bug". Globally, the response from financial institutions was far from proactive. A large Australian bank found itself in a "socio-security gaffe" when a representative blogged about the bank being "patched against the bug", invoking customer outrage demanding to know whether the bank had been vulnerable before the patch was applied. In another case, the CEO of a bank in the Philippines was found to be unaware of the threat in the annual stockholder meeting, which left stockholders baffled.
Reactions such as the above highlight the need to strengthen the rapid response and reaction teams of banks in order to effectively and aggressively tackle vulnerabilities of this scale. In my view, it may be a good idea to proactively inform customers, reassuring them of the safety and security of their data through either a banner message on the website or an SMS/push notification alert. Some banks used social media to reach out to customers which in my view is a fantastic way to relay urgent communication. However this strategy was unfortunately deployed by only a handful of banks. Only one out of four large banks in Australia was proactive in issuing an advisory. Another bank in Australia issued an advisory only when a customer posted a related query on its blog requesting details about the incident and its potential effects. These incidents are in fact opportunities to gain customer trust which financial institutions can't afford to miss.
A different perspective was shared by one of the leading security firms, which raised concerns about the lack of adequate support staff for Open SSL as one of the reasons for the origination of such bugs. It emphasized that there might be several other vulnerabilities which are still unknown and could be potentially harmful when exploited. Drawing co-relation, some financial institutions might rekindle the Open Source vs licensed software debate citing security as one of the major concerns. That being said, regulators are taking concrete steps to ensure customer safety. Recently, the FFIEC in the US requested banks to patch their systems and services, applications, and appliances to ensure they are protected against the Heartbleed vulnerability. However, banks do need to take steps to mitigate the fallout of any future incidents.
A recent analyst report projects that spending on risk information technology in financial services will account for an average of 17.1% of overall IT spending in 2015 and grow to 18.2% of total spending by 2018. A layered security model which enforces multiple and diverse security techniques across all risk touch points can be conceived as a part of this increased investment. This model must be supported by agile processes which provide measurable controls, regular audits and frequent upgrades of the concerned systems, services, applications and devices. Banks can also create an emergency response team which can minimize latency in the deployment of corrective action and communication to internal and external stakeholders.
I believe social media will play an important role in emergency communication. However, the response to incidents should not only include details of the incident and status quo, but also focus upon how customers can protect themselves further through regular use of best practices like frequent password change and Android version upgrade. Sharing best practices in this manner would minimize the potential loss through active collaboration between banks and customers. I am sure we have many things to learn from this incident, but how much of that will be put into practice remains to be seen.