2009/04/16

記事一覧へ >>

　筆者は過去数カ月にわたり，現在のセキュリティ・ソリューションの煩雑さについて，数多くの講演や教育機関向けセミナーを行ってきた。テーマの中心は，Web開発者が基本的にはユーザーを理解せずアプリケーション開発に従事している，ということである。特に，クライアント側での「保護」を強調するあまり，エンドユーザーに「セキュリティ」の責任を押しつけていると説明した。

　読者が「まるでIPS（侵入防御システム）やコンテンツの詳細な検査をけなすような言いぐさだ」という結論に飛躍する前に，Web環境におけるこれら保護技術は万能の解決策ではなく，むしろWebアプリケーション自体のセキュリティ対策が不十分であることを指摘したいと思う。各種取引用アプリケーションをもっと上手に保護する方法は存在する。

　そこで，筆者は2009年4月23日にカリフォルニア州サンフランシスコで開催される「RSA Conference」で，「セキュリティ人間工学」と題した講演を行う。その概要は次の通りだ。

• セキュリティや構成を設定する際にポップアップ警告メッセージが表示され，「許可/禁止/キャンセル」するよう迫られる現状に満足しているだろうか。エンジニアやセキュリティ専門家であれば，このような状況で次に何をすべきかを，提供された情報から判断することができる。それでも，誤った処理をしてしまうことがあまりにも多い。
  それなのに，なぜその失敗を一般ユーザーのせいにするのか。プロなら，セキュリティの責任を自分たちで負うべきだろう。ポップアップ警告で決定を迫るような状況が存在するのは，アプリケーションを開発した「専門家」が，本当は何をすべきか分かっておらず，言ってしまえば「CYA（Cover Your Ass：言い訳）」メッセージで責任をユーザーに押しつけているのだ。

• アプリケーションの高度化や高機能化が進んでいるせいで，セキュリティの脅威や攻撃手段はますます増えている。「必要なことはやった」としてユーザーにセキュリティの責任を押し付けるのではなく，こうした状況を改善するには何ができるだろうか。現状から前進するには，アプリケーションの設計/開発でセキュリティに関する人間工学を考慮する必要がある。

• IT業界は，クライアント側に綿密なセキュリティ戦略を導入することで，セキュリティの責任を最終的なユーザーに押しつける傾向が強まっている。よく見てみると，これらセキュリティ保護策の多くはバックエンド・システムに移管可能だ。
  移管すれば，改ざんやユーザー側での侵入の可能性が減るうえ，「フォールス・ポジティブ」（正当な行為を不正と誤判断すること）や「フォールス・ネガティイブ」（不正行為を正当と誤判断すること）に陥る可能性も少なくなる。企業の事業継続において，最大のリスクは自社のユーザーや顧客だ。企業はこの新たな脅威と向き合わざるを得ないため，人間工学に基づくアプリケーション設計戦略は今後ますます必要不可欠になるだろう。

　この話の前提には，オンライン顧客/ユーザーの相当多くが現在そして今後もマルウエアに感染し，取引のトランザクションの正真性に影響を及ぼす，という状況がある。これまでまかり通っていた，顧客のパソコンを守る試み（例えば「ここに無償のアンチウイルス・ソフトがあるのでインストールしてください」「ここにさまざまな認証に用いるトークンがあるので手元に保管してください」といったもの）は，うまく機能しないのではないだろうか。率直に言って，現在のマルウエアは，大抵の想像より性能と効率が高い。

　筆者は2008年10月，このトピックについて短いレポート「Continuing Business with Malware Infected Customers（マルウエアに感染した顧客との取引継続について）」を執筆し，その後ブログ記事にもした。

　Webアプリケーションのセキュリティ人間工学は非常に多くの側面があるので，具体的な事例を調べる方がよいだろう。当ブログ記事では，我々のほとんどが関与するオンライン・バンキングを取り上げる（これはRSA Conferenceで取り上げる内容のごく一部であり，カンファレンス本番ではその他Webアプリケーションについてさらに多くの新情報が出てくるだろう）。

オンライン・バンキングの調査

　過去10年間，筆者はほぼすべての国際的な大銀行や大手金融機関と，何らかの形で仕事をする機会に恵まれた。したがって，ここで取り上げる分析やアドバイスは，多少の常識と，実施できる先見の明と予算があれば，取り立てて目新しいものではないだろう。

　一般的に，エンドユーザーや顧客がソーシャル・エンジニアリング攻撃（詐欺行為）に引っかかって認証あるいは取引に必要なID情報を他人に渡す可能性があったり，利用するパソコンがマルウエアに感染していたり（インターネットに接続されたパソコンの25〜33％は感染しているらしい）すると，クライアント側でどのような手立てを行ってもセキュリティは守れない。

　企業はクライアント側の「ソリューション」を検討するよう筆者は声を大にして主張し続けたが，企業側が代わりにしたことは，顧客向けアプリケーションを複雑にすることだった。その結果，実際には将来の感染や詐欺行為の攻撃経路が増えてしまう。このような場合，実践的な対策は，保護や検出に関する技術/アルゴリズムをできるだけ多くバックオフィスに移管することだけだ。

　では，どのようなテクニックを用いたらよいだろうか。

1. HTTPのリファラ（REFERER）に注目する：顧客が最初にWebサイトにアクセスしてくる際，参照元が必ず存在する。WebブラウザでREFERER情報を送信しないよう設定することはできるが，（操作の流れに依存する大半のWebアプリケーションが処理を中断してしまうため）このような設定はなされていないことがほとんどだ。ある顧客のREFERER情報がおかしい，あるいは危険な場所からのアクセスという可能性があれば，この顧客とWebアプリケーションのやりとりに注目し，1〜2週間アカウントを監視する。
   　というのも，フィッシング詐欺は，顧客が偽サイトを訪れた際に（おそらく「ロックされたアカウントのリセット」を装って）アカウント用認証情報を盗み出すケースが多いからだ。偽サイトは，情報入手後に顧客のWebブラウザを本物のWebサイトへ自動的にリダイレクトする。REFERERに含まれるURL情報は，被害者を特定するうえで欠かせない手がかりなのだ。
2. Webブラウザのバージョン情報を記録する：顧客がオンライン・アプリケーションで認証するたびに，Webブラウザの種類とバージョンに関する情報を記録する。例えば過去5回分のログイン情報を照会することで，通常とは異なる操作を簡単に検出できる。
   　例えば，いつもは米マイクロソフトのInternet Explorer（IE）を使ってログインしている顧客がFirefoxでログインしたら（そしてその後，再びIEに戻ったら），疑わしいログインである可能性があるため，以後の処理を監視することでオンライン・セッションの正当性を保証できる。あるいは，前回ログインしたときよりも古いバージョンのWebブラウザを使用している場合（前回はIE 7を使用したのに，今回はIE 6を使ったなど），（フィッシング犯が自分のパソコンから不正送金しているといった）何かおかしいな状況に感づくきっかけになるだろう。
3. 地理的なIP情報（GeoIP）：GeoIP情報は非常に便利だ。米国に住んでいる顧客が米国の銀行と取引していて，普段ジョージア州アトランタからDSL接続でオンライン取引を行っているとしよう。こうした情報は，GeoIPで識別できる。この顧客が別の場所（韓国など）のGeoIPで認証を行っていたら，新たな資金移動についてはとりわけ警戒する。GeoIP情報と最終ログイン日時情報を組み合わせると，移動が物理的に可能かどうかという観点から，監視をさらに絞り込むことができる。
4. スパム/フィッシング活動の監視：顧客に届くスパム/フィッシング・メールを監視すれば，メールの量が増え，内容が具体化したときに顧客を狙う詐欺も増えていると考えられる。したがって，新たな攻撃の開始（あるいは詐欺メールが大幅に増えた場合），監視や警戒を強化することで顧客との取引を保証できる。この監視強化は，フィッシング攻撃が継続している間，および攻撃が収束してから2〜5日間行う（顧客がメールを定期的にチェックしているとは限らないため）。
5. 取引のタイミング：現在出回っている不正オンライン・バンキングを仕掛ける高度なトロイの木馬の多くは，1回の認証済みセッショ内で実行する新たな資金移動処理の時間間隔を監視すれば検出できる。トロイの木馬のソフトウエアで実行される，自動化された不正送金を見つけるよりは簡単だ。

　上述したテクニックがすべての解決策を網羅しているというつもりはない。また，当然のことながらWebアプリケーションは千差万別だ。重要なのは，脅威が魔法の弾丸（対策）一発だけで消えたりしないということだ。とはいえ，これらの対策は顧客を詐欺から守るうえで，顧客に面倒な手間を強いることなく，非常に重要な手がかりを提供してくれる。

　筆者が試みるのは，オンライン・バンキング取引を保証するための，いくつかの「ベスト・プラクティス」ならぬ「ベター・プラクティス」である。また開発者は外に目を向け，アプリケーション開発の世界ではびこっている「我々の顧客はよく分かっていない」という見方から抜け出すことだ。

---

Copyrights (C) 2009 IBM, Corp. All rights reserved.
本記事の内容は執筆時点のものであり，含まれている情報やリンクの正確性，完全性，妥当性について保証するものではありません。
◆この記事は，日本IBMの許可を得て，米国のセキュリティ・ラボであるIBM Internet Security Systems X-Forceの研究員が執筆するブログIBM Internet Security Systems Frequency-X Blogの記事を抜粋して日本語化したものです。
オリジナルの記事は，「RSA 2009 - Security Ergonomics & back-office anti-fraud protection techniques」でお読みいただけます。