Connect with us

Perspectives

Patch, patch and patch: avoiding a cloud Meltdown

DigFin invites Padraig Walsh to discuss implications for fintechs reliant on cloud vendors in light of recent security flaws.

Published

on

Many fintechs have based their business model on cloud computing. By outsourcing the heavy computational lifting to the likes of AWS, Azure, Aliyun or others, they can offer clients cutting-edge service at razor-thin costing. Financial institutions, meanwhile, are tentatively exploring the benefits of moving surge activities to cloud vendors.

Padraig Walsh, partner, Bird & Bird

This pretty picture was marred in late December with the news that the chips used for cloud services and mobile phones, produced by the likes of Intel, AMD and ARM Holdings included flaws making it possible for hackers to steal encrypted information. While “Spectre” is a Microsoft-specific vulnerability, “Meltdown” enables a program running on an Intel chip to bypass the operating system (OS) and access data in separate programs.

As chipmakers scrambled to release patches, confusion deepened in January when a Microsoft official in the U.S. suggested users might prefer not to address these flaws if it meant losing performance – a tempting thought for many startups.

DigFin asked Padraig Walsh, Hong Kong-based partner at Bird & Bird, a law firm with a fintech clientele, to suggest how fintechs relying on cloud computing to think about this problem. He writes:

Here’s a dilemma. Patch your software to account for latent deficiencies in CPU processors: lose performance, but avoid or mitigate data breach. Or do nothing, and this latent deficiency may result in a systemic data breach (and by the way, your chances of being targeted have increased). For fintech businesses, Spectre and Meltdown provide this “damned either way” scenario.

Realistically, there is no choice. The only decision is to patch, patch and patch again, with every solution and update provided by any operating system (OS), cloud or app service provider. Users have to use the recommended precautionary measures recommended to mitigate their own liability.

Fail to do that, then a systemic data breach may mean any number of nasty outcomes. In Hong Kong, there is the prospect of an action from the Privacy Commissioner (if personal data is involved). One of the core privacy principles in Hong Kong is that a data user must take practicable steps to safeguard personal data from unauthorised or accidental access, processing, erasure, loss or use. Similar rules apply elsewhere.

There could be regulatory action from a regulator such as the HKMA or the SFC, if the business is a regulated entity. Also, if there is a breach of contract or confidence, then there could be civil claims with catastrophic consequential damages. So, serious stuff.

There are four areas of potential liability:

  • Product liability: Intel and ARM have said the problems do not arise from a design defect or flaw. Intel has characterized this as a weakness in how all processors have been designed. It is true that a number of processor firms have been affected. That is likely to be tested in court. Class actions have already been filed in the U.S.
  • Delay: Google informed CPU manufacturers of the design flaws on 1 June 2017 for Spectre and 28 July 2017 for Meltdown. The planned announcement was scheduled for 9 January, but was rushed to 4 January 2018 when news leaked. Did the CPU manufacturers work fast enough? Should the news have been released to market sooner? Could end user losses have been avoided? Pending litigation will argue this.
  • Ongoing losses: The security solutions to mitigate Spectre and Meltdown will result in a loss of performance. For older OS using these CPUs, this could be up to 30%. Realistically, in the financial services sector, it is unlikely to be as bad as that. However, marginal performance deterioration could arguably give rise to significant impairment of financial returns. Also, not all businesses may implement the measures at the same time, potentially magnifying the loss for some. It will be difficult to prove causation – namely, that patches to address Spectre and Meltdown resulted in specific losses that otherwise would not have occurred. But, I expect there will be litigants who will try to prove just that.
  • Supplier losses: Apple, Microsoft, Google, Amazon and Linux are just some of those who have provided patches to address the risks of Spectre and Meltdown. They have incurred costs in doing so. They are likely to believe those costs are recoverable from Intel, ARM and other CPU manufacturers.

What does this mean going forward?

Cloud computing is most vulnerable to these design flaws. Nonetheless, Spectre and Meltdown are highly unlikely to discourage cloud-computing use, provided the industry responds with confidence to demonstrate safety. Its use is too embedded in business operations now.

Here is AMD’s sensible statement: “Total protection from all possible attacks remains an elusive goal”. CPUs – like all technologies – are designed by humans. There will be flaws.

(These comments express the personal views of the author, and not the official opinion or views of Bird & Bird. Nothing in these comments is intended to, or actually provides, legal advice.)


DigFin direct!

Register to receive DigFin's newsletter

 
  • Hauptseite
  • Grocery Gourmet Food
  • Patch, patch and patch: avoiding a cloud Meltdown