{{item.title}}
{{item.text}}
{{item.title}}
{{item.text}}
2017-09-26
筆者は2014年から3年間、金融庁の監督局総務課(システムリスクモニタリング担当)および総務企画局のサイバーセキュリティ対策企画調整室に在籍し、ITリスク・サイバーセキュリティに焦点を当て金融行政に携わってきました。その中でも印象的であったインシデントの1つが本日取り上げるテーマにかかわるものです。具体的には2015年から2016年にかけ、複数の外国銀行にサイバー攻撃が仕掛けられ、国際的な金融インフラであるSWIFTを悪用した多額の不正送金事案が発生しました。また、これらの事案を重く受け止めたSWIFTは「SWIFT Customer Security Controls Framework」 を構築・導入し、全てのSWIFT利用組織にセキュリティ強化を促す取り組みを開始しました。そこで本コラムでは、この一連の出来事を題材とし、「SWIFT Customer Security Controls Framework」の内容と利用組織に求められる対応について紹介したいと思います。
なお、本コラムにおける意見・判断に関する記述は筆者の私見であり、所属組織の見解とは関係のない点をあらかじめお断りしておきます。
2016年2月にバングラデシュ中央銀行のSWIFTが悪用され不正送金事案が発生したことは記憶に新しいと思いますが、それ以外にも2015年から2016年にかけエクアドル、ベトナム、フィリピン、インドなどの銀行でも同様の事案が発生していると言われています。
攻撃手口はいわゆる“Targeted Attack“であり、サイバー攻撃犯罪者によって利用組織のSWIFT端末がマルウェアに感染させられた上で、遠隔操作されるなどにより、偽の送金メッセージが作成・発信されてしまい犯罪者の口座へ多額の資金が送金されるというものです。もちろんSWIFTネットワーク自体はクローズなネットワークであり、高度なセキュリティ対策が実装されているわけですが、エンドポイントとなる各利用組織に設置されたSWIFT端末やメッセージ送受信を管理するサーバーなどのセキュリティが脆弱(ぜいじゃく)である場合は、今回のような事案につながってしまいます。SWIFTは200カ国以上の11,000を超える利用組織が参加しており、いわば加盟組織同志の信頼関係で成り立っている共通インフラです。そのため、大半の利用組織が堅牢なセキュリティ対策を施していたとしても、一部の利用組織が脆弱(ぜいじゃく)であれば、その弱点を突かれ、SWIFT全体の信頼性と安全性を毀損(きそん)させるインシデントが起こってしまいます。
そのため、SWIFTは、全てのSWIFT利用組織に一定水準以上のサイバーセキュリティの確保・維持を求めるとともに、SWIFTコミュニティ全体のセキュリティ水準の強化を図るために「Customer Security Programme(以降、CSP)」を導入しました。CSPには「必須のセキュリティコントロールの導入」、「不正行為の防止・検知を支援する新しいサービスの提供」、「将来の攻撃に対する準備、防御のためのコミュニティ全体の情報共有イニシアチブ」などが含まれますが、このうちの1つ目が本コラムで取り上げる「SWIFT Customer Security Controls Framework(以降、CSFと記載)」です。
CSFの概要については、以下の通りです。
【図表1】SWIFT Customer Security Controls Frameworkの構成
※SWIFTのホームページなどの情報を基に整理・仮訳
以降のパラグラフでは、上記1.~3.のうち、関心が高いと思われる1.と2.について、留意すべきポイントを含めて解説します。SWIFTまたはCSFの対応を担当される方々は、合わせてご覧いただければと思います。
CSFは、3つの「目的(Objectives)」と、8つの「セキュリティ原則(Principles)」、27の「コントロール(Controls)」で構成され、27のコントロールで構成されています。また本構成には次の2つの特徴があります。
1点目はコントオールが16の必須項目と11の推奨項目に分類されている点です。SWIFTは、利用者組織に対して16の必須項目について、全て遵守することを要求しています。一方、11の推奨項目については、SWIFTは利用組織に実装を推奨する優れたコントロールであると説明しています。
しかしながら、ここには留意が必要です。現時点では推奨項目としつつも将来的な外部環境などを踏まえて必須項目への格上げ・見直しをする可能性を示唆しています。そのため、利用組織は必須項目への対応に焦点をあたるだけでなく、できる限り推奨項目への対応についても前向きに検討しておくことが望ましいでしょう。また、これら27のコントロールは、サイバー脅威のインテリジェンス分析や業界の専門家、ユーザーの知見を踏まえて策定したとされているため、形式的な必須か推奨かという分類の枠としてとらえず、自組織のリスク低減、あるいは管理水準の高度化の観点から、可能な限り対応を検討してみるとよいのではないでしょうか。さらに言うなれば、27のコントロールはSWIFT以外にも当てはめることが可能な汎用(はんよう)性をもった内容となっています。そのため、他のシステムのセキュリティ強化あるいはギャップ分析の際の着眼点としても活用可能となっています。
2点目の特徴は、オブジェクティブベースで構成されている点です。コントロールを実装する際の詳細かつ具体的な説明は実装ガイドとしてユーザー向けドキュメントに記載されていますが、SWIFTは、必ずしも実装ガイドに書かれた字句通りの対応を求めているわけではありません。「コントロールの目的を満たすことができ、有効な対策が実装でされている場合は、実装ガイド通りの対策(手段)でない場合でも”Comply(遵守している)”と判断することが可能」としています。このような考え方は自然であり合理的です。もちろん、採用する代替的コントロールが対応する目的を的確に満たすことができているか否かは慎重に見極める必要はあるものの、利用組織は実装ガイドの字句どおりの対応に固執せず、実質的かつ効果的な方法で対応を進めるとよいと思います。
【図表2】必須コントロールと推奨コントロール
1 |
SWIFT環境の保護 |
2 |
オペレーティングシステムの特権管理 |
3 |
SWIFTの内部データフローのセキュリティ確保 |
4 |
適時のセキュリティの更新 |
5 |
システム強化と潜在的な攻撃対象の削減 |
6 |
物理的セキュリティの確保 |
7 |
効果的なパスワード管理ポリシーの確立 |
8 |
多要素認証による認証機能の強化 |
9 |
論理的アクセスに対するセキュリティの確保 |
10 |
トークンの管理 |
11 |
不正ソフトウエアの検知 |
12 |
SWIFT関連ソフトウエアの整合性の確保 |
13 |
データベースの整合性の確保 |
14 |
ログ取得とモニタリング |
15 |
サイバーインシデントレスポンスの確立 |
16 |
セキュリティ教育と啓蒙 |
※SWIFTのホームページなどの情報を基に整理・仮訳
1 |
バックオフィスで扱うデータフローのセキュリティ確保 |
2 |
外部向け送信データの保護 |
3 |
オペレータセッションの機密性と完全性の確保 |
4 |
脆弱性スキャニングの実施 |
5 |
重要な外部委託業務の管理 |
6 |
トランザクションに関する業務の管理 |
7 |
身元調査プロセスの導入 |
8 |
パスワード情報の物理的・論理的記憶領域の保護 |
9 |
侵入の検知 |
10 |
ペネトレーションテストの実施 |
11 |
脅威シナリオベースのリスクアセスメントの実施 |
CSFのもう1つの特徴が、「Self‐Attestation」制度の導入です。本制度は利用組織に対し毎年の自己評価の実施と評価結果の提出を求める内容です。また自己評価が未実施の利用組織や必須コントロールを遵守できていない利用組織について、SIWFTが当局へ通知することが可能となっています。このような制度が特定の情報システムに適用されるケースはまれであり、そのことがCSFの注目度を高める結果となりました。さらに言えば、時を同じくしてNYDFS(ニューヨーク州金融サービス局)が導入した規制「Cybersecurity Requirements For Financial Service Companies」も、SWIFT同様に年次で規制内容への遵守を当局報告させるスキームを採用しており、両者がほぼ同タイミングで施行されたことも注目度を高めるきっかけになったかもしれません。(NYDFSの規制については、また機会があれば別コラムでご紹介したいとおもいます。)
Self‐Attestationの概要は、以下のとおりです。
【図表3】Self‐Attestationの概要
Self-Attestation(自己評価)の概要 |
|
Who |
すべての利用者組織が、自身あるいは外部監査法人等を利用し自己評価を実施 |
What |
16の必須コントロールを遵守しているか否かを自己評価し、結果はSWIFTに提出 |
Where |
自己評価を毎年実施。初回は2017年12月末まで |
When |
自己評価の結果は、「SWIFT KYC Registry Security Application」を通して提出 |
Why |
SWIFT利用組織のセキュリティの強化ならびに取引先に対する透明性、説明責任の確保 |
How |
|
※SWIFTのホームページなどの情報を基に整理・仮訳
あわせて、いくつかの留意すべき主なポイントを以下で解説したいと思います。
まず、16の必須コントロールへの対応について。
いくつかの必須コントロールに対応するためには、投資を要するものや改善対応に時間を要するものがあります。システムの性質上、IT部門とSWIFTを所管部門が連携して対応を行う必要がでてくると想定されるため、早めの準備・対応が望まれます。しかしながら、初年度の段階では完全に遵守していると回答することが困難な利用組織もでてくると想定されます。その場合は、「KYC Registry Security Application」の該当項目を”Not Comply(遵守できてない)”とした上で、補足説明欄が設けられているため、当該欄にいつまでに改善し遵守する計画であるかなどを記入することが可能です。代替コントロールにより対応する場合も同様にその旨の説明を補足欄に記入します。
なお、上図の”How”に記載のとおり、SWIFTが公表している情報によれば、初年度2017年の自己評価に関しては必須項目を完準に遵守できていない場合でも、自己評価結果を提出さえすれば、当局へ通知される可能性はないものと考えられます。そのため、SWIFTが公表しているQAにも記載されている通り、利用組織は、完全遵守できている/できていないということのみに固執するのではなく、適切な評価を実施し、正確かつ完全な自己評価結果を提出する必要があります。
“It remains each user’s responsibility to submit a correct and complete attestation for all mandatory controls.“
次に、評価基準日の考え方について説明します。Self‐Attestationは、一律の評価基準日は設定されていません。12月末までに評価結果を提出すれば問題ないため、一度早めのプレ評価を実施し未充足事項を洗い出したうえで、改善対応を実施し、12月末までに再評価を行った上で、結果を提出することも可能です。
以上、代表的な留意点を記載しましたが、その他にもSWIFTがユーザー向けに発行されているガイドやポリシーはもちろん、ホームページ上に公開しているQA集にもSelf‐Attestationに関する詳細な情報が記載されているため、関係する方々は目を通してみるとよいと思います。
以上、ここまでSWIFT Customer Security Controls Frameworkの主なポイントを解説してきました、
サイバー攻撃の多様化・巧妙化はますます進んでおり、そのトレンドは残念ながら今後も続いていきます。中でも金銭目的の攻撃は、その傾向が顕著であり被害も深刻化しているように感じます。本コラムでは、SWIFTを悪用した不正送金を取り上げましたが、近年ではATMのハッキングによる不正出金や、サイバー攻撃で窃取したカード情報から偽造カードを作成し不正出金するケースなども発生しており、多額の資金が直接盗取できる金融分野への攻撃は犯罪者にとっても大きなインセンティブとなっています。
他方、防御側の金融機関などは、対策を尽くしても全てのサイバー攻撃を未然に防御することはもはや困難となっており、資産やサービスが影響を受けることを前提に対策を講じる心構えが重要となります。
多くの利用組織の方々はすでに初回の提出期限である2017年末に向けて計画的に対応を進めていると思いますが、本コラムが少しでも今後のセキュリティ強化の参考になればと思います。
なお、本コラムの執筆に当たってはSWIFTのホームページなどの情報の他、以下の文献を参考にしています。以下は筆者が金融庁在籍時代に共著したものであり、本コラムとはまた少し異なる視点からまとめているため、ご関心のある方はご覧いただければと思います。
(参考文献)
週刊 金融財政事情(2017年9月18日号)
テーマ:SWIFTの不正送金事案から探るサイバーセキュリティ態勢