SWIFTが主流である理由

SWIFTは当初、トレジャリー取引とコルレス取引の支援のみを目的として設立されました。現在も、送金ベースのメッセージがトラフィックの50％近くを占めていますが、43%は証券取引に関連するメッセージとなっています。残りのトラフィックはトレジャリー取引に関連するものです。200以上の国と地域にある11,000以上のグローバルな金融機関を結び、1日に1,500万件（年間50億件）以上の金融メッセージがSWIFTNet上で交換されています。

SWIFTの利用者

SWIFTの堅牢なメッセージ形式には非常に大きな拡張性があったため、徐々に拡大されて以下の各業種にサービスを提供するようになりました。

• 銀行、証券仲買会社、商社
• 証券ディーラー
• 資産管理会社
• 清算機関、預託機関、取引所
• 事業法人
• 債券市場の参加者とサービス提供者
• 外国為替ブローカー、金融ブローカー

SWIFTは、顧客に代わって資金の保管や口座の管理を行っているわけではありませんが、世界中のユーザコミュニティの安全な通信を可能にしています。標準化された金融メッセージを信頼のおける方法で交換することで、国内外の資金の流れを促進し、国際商取引を支えています。

SWIFTの重要なコンポーネント

図1：幅広い金融機関の間で安全な取引メッセージ送受信を
実現するSWIFTインフラストラクチャ

SWIFTNet：SWIFTNetは、ネットワークに接続されて参加しているすべての金融機関のアプリケーションに対し、汎用のインターフェイスを提供します。アクセスは、インフラの技術的制約によってではなく、各サービス管理者の経営方針上の判断によって制御されます。

SWIFTNet Link：ビジネスアプリケーションは、すべての外部インターフェイスでSWIFTNet Link（SNL）APIを使用してSWIFTNetサービスにアクセスします。そのバックグラウンドプロセスは、メッセージング、セキュリティ、およびサービス管理の機能をサポートしています。これは、SWIFTAlliance WebStationとSWIFTAlliance Gatewayに組み込まれています。

SWIFTAlliance Gateway：SWIFTAlliance Gateway（SAG）は、異種のコンピューティングプラットフォーム上で稼働するビジネスアプリケーションに対し、SWIFTNet経由のメッセージ送信を許可します。メッセージは、WebSphere MQホストアダプターなどのホストアダプターを通じて受信されます。

図2：Alliance Messaging Hubのアーキテクチャの概要

Alliance Messaging Hub：Alliance Messaging Hub（AMH）は、複数のグローバルネットワークへのメッセージ処理により、顧客の事業活動を支援します。スケーラブルでカスタマイズ可能なAMHは様々なメッセージングサービス間のルーティングを提供し、いくつかの統合に対応しています。技術スタッフは、独自の業務フロー、変換、レポート定義、複雑な業務ルーティングを作成できます。

SWIFTメッセージの流れ

SWIFTメッセージ（FIN）の準備は以下の手順で構成されています。

• メッセージ作成：ユーザはメッセージ作成アプリケーションにアクセスして、SWIFTメッセージを作成します。各メッセージはタイプとフォーマット、および金融機関が定義した権限とルーティングに応じて処理されます。

• メッセージ検証：メッセージ検証アプリケーションでは、受渡日、通貨、金額など、SWIFT FINメッセージの重要なフィールドを検証します。ほとんどの場合、メッセージ作成者はメッセージを検証しません。その代わりに検証者が、空欄で表示されたこれらの重要なフィールドに値を再入力します。フィールドセットが一致しなければ、メッセージの検証は成功しません。検証待ちのメッセージは、メッセージ検証キュー（_MP_verification）に保持されます。

• メッセージ承認：検証されたSWIFT FINメッセージとシステムメッセージは、メッセージ承認アプリケーションで送信を承認します。この際に目視チェックを行います。通常、メッセージ承認キュー（_MP_authorization）に保持されている承認メッセージは監督者が承認します。承認すると、メッセージがそのメッセージ内で指定されたネットワークキューに伝送されます。Alliance Accessが、ネットワークキューからメッセージを自動的に転送します。

抜け穴と既知のSWIFT不正問題のコントロール

ある大手銀行からの報告によると、以下の2つのケーススタディにSWIFT取引の抜け穴が記録されています。

1つ目のケースでは、金融機関が、確認者-作成者間の取引を検証するフリーフォーマットメッセージの作成、検証、承認、送信について、二重の制御プロセスを確立していませんでした。その結果、金融機関とそのコルレス銀行間でやりとりされた送金命令の修正に関する一連のSWIFTメッセージが、監督者による確認に回されていませんでした。

調査したところ、人手不足が原因で、監督者が融資金支出承認前のデューデリジェンスを怠っていたことがわかりました。インバウンドSWIFTメッセージの受信と配信のコントロールが不十分だったため、ある銀行員が抜け穴を利用して、貸付処理をもう一度呼び出し自分の個人口座に送金していました。

最近発生したもう1つのケースには、取引検証プロセスの悪用が絡んでいました。このプロセスは3つの手順からなり、作成者がSWIFTメッセージをシステムに入力し、確認者がチェックし、検証者がその真正性を確認したうえで送信します。しかしここで、貸付の作成を確認するメッセージの作成者、確認者、検証者、受信者のうち3人以上の担当者が共謀（このケースでは同一人物が実行）することで不正を可能にしていました。

金融機関による主要な検知のユースケース

• SWIFTメッセージの作成者の役割を持つ人と、確認者の役割を持つ人との間の異常な関係の検知を求める金融機関、また実際に検知できる金融機関はわずかです。ある調査によれば、特定の確認者が、関連するメッセージ作成者に対する最も頻繁な承認者になっている場合に、不正取引が発生するおそれがあります。
• FINメッセージ承認者は、メッセージ作成者またはメッセージ検証者とは別であるべきです。FINメッセージの作成と承認または承認と検証が、同じ端末からまたは同じ人によって行われた場合には、疑わしい取引として検知できます。
• 通常、作成者と確認者は、普段使用している端末から通常の営業時間内にFINメッセージアクティビティを実行します。作成者と確認者の通常とは異なるログインアクティビティを監視すると、不正アクティビティを検出できます。

Exabeam Advanced AnalyticsがSWIFT不正を防止する方法

Exabeam Advanced Analyticsは、異常なアクティビティを検知するために、機械学習と行動分析を用いてユーザとデバイスの基準（ベースライン）を作成します。Windows Active Directory（AD）、プロキシ、ファイアウォール、セキュリティアラート、データベース、その他のアプリケーションからログを取り込むことができます。

最新のデプロイメントに基づき、少なくとも7つのイベントタイプをSWIFT Alliance Gatewayログからキャプチャできます。そのうち3つはSWIFTメッセージに関連し（メッセージの作成、検証、承認）、4つはログインアクティビティに関連します。

図3：Exabeam Advanced Analyticsで作成されたSWIFTイベント

仕組み：Exabeam Advanced Analyticsは、Alliance Gatewayのログを受信すると、これを解析および正規化して、図3に示すように特定のSWIFT関連アクティビティに対応するイベントを作成します。

図4：アプリケーションイベントを示すAdvanced Analyticsのユーザセッション

各ユーザおよびデバイスのアクティビティの基準を作成するために、機械学習と行動分析を用いてセッションタイムラインが作成されます。図4に示すように、SWIFT関連イベントは他の環境ログ（Windows、プロキシ、メール、プリンタなど）から取得した他のイベントとともに、ユーザのタイムラインにつなぎ合わされます。

図5：Advanced Analyticsによる、ユーザのアプリケーションアクティビティに関連する学習済み行動モデルの表示

行動モデルは、Alliance Gatewayログ（図5）から、以下のように様々な基準を学習できます。

• 各ユーザとその部署が取り扱うFINメッセージタイプ
• 1週間のうち、SWIFTメッセージが処理された時間帯
• 各SWIFTユーザが通常使用するデバイス
• Advanced Analyticsは、学習済み行動モデルと確立済みリスクルールから、リスクエンジンを用いて異常なSWIFTアクティビティを検知します。例えば以下のようなものです。
• メッセージ作成者が特定の承認者を頻繁に使用している場合、両者の間でSWIFTメッセージ承認が行われたときにアラートが発生する。 仕組み：行動モデルにより、Advanced Analyticsは特定の承認者に対するメッセージ作成者や、特定の検証者に対する承認者を学習します。作成者が、承認者を頻繁に（30%超）使用している場合、Advanced Analyticsによってアラートが発生します。同様のモデルやルールを、承認者と検証者に対しても作成できます。

他の検知ルールの例には、以下のようなものがあります。

• 作成者と確認者（検証者または承認者）が同じマシンを使用している場合にアラートが発生する。
• 作成者と承認者が同一ユーザの場合にアラートが発生する。
• FINメッセージが異常な時間帯に作成された場合にアラートが発生する。
• FINメッセージが通常と異なる国に対して作成された場合にアラートが発生する。
• これまでに作成者と関連付けられたことのない端末でFINメッセージ作成が発生した場合にアラートが発生する。

SWIFTと同様のアプリケーションにおける異常で不正なアクティビティの検知

Exabeamが金融アプリケーションで異常かつ高リスクのアクティビティを検知する方法を、以下の例に示します。

図6：ユーザの学習済み通常行動

まず、Exabeamは通常のユーザ行動の基準を作成します。機械学習と行動モデリングを用いて、Advanced Analyticsは組織の全ユーザのアプリケーションアクティビティタイプを学習します（図6）。

図7：過剰で異常なアプリケーションオブジェクトのアクセスまたは取引

アプリケーションオブジェクトへのアクセスなどのアクティビティに関する行動モデルをさらに学習することで、図7では、300以上のアプリケーションオブジェクトにアクセスしたユーザの異常アクティビティをAdvanced Analyticsのリスクエンジンが検知しています。

図8：Advanced Analyticsのピアグループ比較による異常アクティビティの検出

図8は、ピアグループ比較に基づいて異常アクティビティがどのように検知されるかを示しています。

図9：Advanced Analyticsによる異常な時間に発生したユーザアクセスの追跡

図9では、Exabeamが長期休暇中のユーザのアクセスを追跡して疑わしいアクティビティを検知しています。

図10：Advanced Analyticsによる、あらゆるアクティビティの評価およびリスクスコアの割り当てと、事前定義済みのしきい値に基づいたスコアに対応するアラートの生成

ここでは、Advanced Analyticsが、通常状態、ピアグループ比較、異常行動に基づいてリスクスコアを割り当てています。

まとめ

Exabeam UEBAを使用して異常で変則的なアクティビティを検知することで、金融機関はSWIFTログを他のインフラログとともに分析できます。これにより、SWIFTイベントの迅速な検知、SWIFTイベントと他のインフラ関連インシデントとの相互関連付けに加えて、完全な可視性が得られます。予め用意されたいくつかの検知手法を利用して追加の行動モデルとルールを作成すると、さらに細かい検知が可能になります。

Harjith Prabhakaran
Exabeam, Inc. シニアセールスエンジニア