テスコ銀行（英国）ハッキング（クラッキング）被害、銀行安全神話崩壊

イギリスのテスコ銀行がハッキング（クラッキング）され、口座凍結措置されている事が2016年11月7日に同行より公表されました。

以下、被害者のツイッターです。

「最悪の週末だ。私の口座からお金が消えた Money has vanished（消えた） from my account。（ありったけの皮肉を込めて）ありがとうテスコ銀行 。電話対応の返答もない」

「こんな大切な事、なぜ速く会見を開かないんだ」

「テスコ銀行最悪」

など。

参考：英テスコ銀行、ハッキング攻撃により4万口座で資金が引き出されるなどの不正操作

被害は4万口座に及ぶ模様で、ネットバンキングとATMとカードの運用全面停止、口座凍結措置を行い、被害防止と原因究明が続いています。

保証

今回の同行の被害者については、テスコ銀行側より全額保証の旨が発表されています。当然だと思います。

銀行安全神話崩壊

2008年までテスコはスコットランドロイヤル銀行のシステムを利用、その後、ロイヤルから離れてシステム独自運用に変更しています。

金融系のシステムには、ハッキング等の不正が見つかると警告が出る様になっているため、その警告により銀行がハッキングに気づいた模様です。

大手銀行崩壊の前例は今まで無かった

上記参考のbusinessnewslineによると、大手銀行のハッキングは前例が無いとのことで、テスコ銀行は歴史的な被害者補償/訴訟/不名誉、一番乗りをあげてしまった状態です。

発覚原因

システム上、1人のクレジットカードアカウントに対して、複数の場所から数分の間に利用があった場合にアラートが発生するようになっており、そのアラートにより発覚。

未だ原因不明

速く解明され、犯人が捕まり、被害を受けた方々が元通りの預金残高に一刻も早く保証されます事を強く祈っております。

原因が判明次第、日本の金融機関も情報共有をテスコ銀やシステム開発企業へ依頼し、システム対応アップデートなどが必要な場合は速やかに予防措置強化を行う事を一般預金者として国内の金融機関に必ず行って欲しいと強く感じました。

原因について

2016年12月31日に調べた様子では、フィッシングメールでもなく、マルウェア感染などでもなく、銀行のWEBサイトもしくはシステムのメインサーバーやデータベースなどに直接物理的にクラックされていた？などまだ特定されていない様です。WEBサイトやサーバー等のアップデート作業で新たな脆弱性が生まれた可能性、内部関係者による情報流出などの可能性、システムに接続している第三者システムの脆弱性、なども示唆されており、混迷している様です。原因特定が出来ても公表しない可能性もありそうです。

2014年にもテスコは顧客情報流出

2014年にテスコ銀行は顧客情報流出、そのうえインターネット上にその情報が公開されてしまっています。

CRMなど顧客ビッグデータ活用

テスコ銀行は、ポイント導入をはじめとしてCRM（Customer Relationship Managemant）顧客関係管理の開発に積極的な数少ない金融機関の様です。

WEB業界でいうと、アドエビスなどのマーケティングツールなどが比較的に近いです。ポイントシステムの実装は、会計としての負債の知識やポイント付与のタイミングなども含めて複雑です。システム開発会社直営の自社プロダクトであればリスクを抑えやすいですが、システムオーナーが金融機関である場合、経営層や事業部長などの責任者ポジションにシステム開発技術者の不在が予測されます。

発注主のITリテラシーの低さは、大きな瑕疵の見過ごし要因となります。優れた技術者集団を組織内に内製化できなければ、このようなリスクは極めて高い。システム開発部門の内製化は必須。本来、システムの予算計画も優れた技術者を内製化しないと精度の高いものは作られません。システム発注主は、発注する前も制作途中も運営中も固執してセキュリティの学習を永遠に続ける必要が絶対的に有ります。発注主は、お金を払う上に、自らの時間も捧げる必要がある事を忘れないでください。それが運営責任です。丸投げで楽をしようとする発注主は最悪の結果を招きます。

なぜ内製化なのか

外注では、発注金額に対して出来る作業量の限界があります。システムの微妙な修正などは放置されるでしょう。

システム開発会社はプロです。契約書には金額の枠を超える様な部分の瑕疵担保責任は一切無いと明記します。専門性が高い分野の契約は、相手が素人であれば、受注側にとって非常に有利な契約を結ぶことが出来ます。発注側も第3者などの司法の専門家のアドバイスを仰ぐかもしれませんが、技術法務は受注者が全てです。司法の専門家は、技術の専門家ではない。

システム開発はトライアル＆エラーの繰り返しであるため、一回の発注で200億円！など金額上限のある賃金形態には根本的に向いていない。システム開発は見積できない業種です。無理やり見積をしています。完璧な納品はあり得ない。技術者によるイニシャル開発とサービスローンチ後の永続的二次開発は必然です。永続を前提に考えられない金融機関のシステム部門管理責任者は、今すぐ職を辞していただきたい。オブジェクト指向プログラミングやクラウド上のインフラなど、開発実務がわからない経営幹部層が発注管理するより、はるかに安全になります。

自社でシステム開発技術に長けろ！でなければ金融機関は責任を取る術を持てない。そんな金融機関は金貸し事業の資格を剥奪するべきです。そんな金融機関に預金は預けたくない。

システム開発の外注は対応限界があります。システム開発会社が一番よく知っている。

日本がIT後進国である理由です。米国の様に技術者の内製化を当たり前にするべきです。

セキュリティ商品開発の必要性

弊社の様な弱小でも、WEBサイトのクラッキング被害後の調査依頼が新規クライアント獲得という残念なパターンのお問合せをいただくことがあります。

セキュリティ商品開発の必要性を強く感じる事が増えてきているため、Kali Linuxによるペネトレーションテスト（ハッキングテスト）やSE Linux等によるソリューション開発など、規模は小さくても着実に商品開発を始めていく所存です。