Internet Infrastructure Review（IIR）Vol.28
2015年8月31日発行

機械学習とは

セキュリティ分野への応用

既に機械学習の手法を組み込んだセキュリティ製品も存在します。例えば、スパムメールの判定に使われるベイジアンフィルタは、単純ベイズ分類器という機械学習の手法を応用した技術です。他にも、通信ログを学習して攻撃やマルウェアなどの異常を検知する製品、通信パケットを学習してマルウェアの通信を検知する製品などがあります。マルウェア検知の分野では、マルウェアのバイナリや振る舞いの特徴を学習させ、その結果を検出エンジンに組み込んだクライアント機向け製品が存在します。

個別の製品だけでなく、インシデント対応の現場に機械学習を応用している事例もあります。インドネシアのId-SIRTIIでは、IDSを多数導入している環境で、シグネチャでは対応していない攻撃についてそれぞれ機械学習による検知エンジンを開発し、自らの状況に合わせた攻撃検知システムを構築しています（※43）。 また、セキュリティ担当者にとって情報収集の作業は欠かせません。他の企業や組織で発生したセキュリティ上の事件・事故の情報を日常的に収集し分析することもその1つです。オランダのNCSC-NLでは担当者の分析作業を支援するために、収集したニュース記事に対して機械学習を適用し、同一事象に関する記事のグループ化と、カテゴリ別のタグ付け（DDoS攻撃、情報漏えいなど）を自動で行うシステムを開発しています（※44）。

ここまで、機械学習の手法を組み込んだ個別のシステムについて見てきました。次に、現実の脅威として3つ、内部犯行、標的型攻撃、Webサービスへの攻撃を例にとり、それぞれ機械学習を適用することで有効な対策ができるかどうか検討します。

脅威への対策

機械学習システムのセキュリティリスク

機械学習の手法を導入することで新たなリスクは発生するでしょうか。

容易に考えられるのは、機械学習を組み込んだシステム自体への侵入です。システム内部を操作され、攻撃を見逃すように改ざん、停止される危険性が存在します。もっとも、これは機械学習に限らず、監視システム全般に存在するリスクと言えます。

また、設置環境から正常、異常の判別基準を継続的に学習していくシステムでは、別のリスクも存在します。ゆっくりとした変化で、徐々に本来の量や質に近づけていく攻撃をされた場合に、それを正常と判断して見逃す可能性が考えられます。

例えば、ファイルサーバから資料を1通取り出して外部に送信したとします。1通だけなら攻撃ではないと判断して、正当な外部送信として学習するかもしれません。次に別の資料を2通取り出して外部に送信すると、1通は正常なので、2通も正常と判断されて学習するかもしれません。これを繰り返して、最終的には大量の資料を外部送信できるかもしれません。

これもアノマリ検知の技術が登場したときに、既に指摘されていたことです。仮に、攻撃完了までに非常に長い期間を要するのであれば、攻撃のハードルはそれだけ高いと言えるでしょう。そのためには学習が緩やかである程望ましいということになりますが、その一方で正当な業務利用の形態の変化には素早く追従することが望まれます。このジレンマの解決には、両者の適切なバランスを見極めることが必要です。

機械学習の導入リスクに関する議論は、いまだ十分になされたとは言えない状況です。今後、新たな指摘が出てくる可能性もあり、引き続きその動向に注目する必要があります。

まとめ

セキュリティ上の事象の検知、分析、対応にかかる作業を自動化と迅速性で支援することは、セキュリティ関連技術の大きな目的の1つです。ブラックリストとホワイトリストに代表される、明確な異常と正常を列挙する方法論では、現実的に列挙が困難な、広大な中間域が残ります。この中間域を自動的に解消できる可能性を持った手法として、機械学習が期待されており、今後も機械学習の適用例はますます増えていくと考えられます。

攻撃の流れと隠蔽手法

本稿執筆時点（2015年7月下旬）に観測されているAnglerの典型的なURL遷移の例を示します（図-18）。この例では、改ざんされたWebサイト内のHTMLコンテンツに、外部のJavaScriptファイルを読み込むScriptタグが挿入されており、そのファイルから更に別のサーバ（Infector）に設置された、悪意あるJavaScriptを含むHTMLファイル（以下「Landingpage」とする）を読み込ませます（※46）。

拡大する

図-18 Anglerの典型的なURL遷移の例（2015年7月）

Landing pageは150KB前後の英文ドキュメントのHTMLコンテンツを装っていますが、多段に難読化されたJavaScriptを含んでいます（図-19）。

また、このLanding pageには、IEのリソース情報漏えいの脆弱性（CVE-2013-7331/MS14-052）などを悪用して仮想化環境やアンチウイルスソフトウェアなどを検知する仕組みを備えており（※47）、それらが見つかった場合は以降の攻撃は行われません。対象としている仮想化環境やアンチウイルスソフトウェアが検知されなかった場合、IEのメモリ破損の脆弱性（CVE-2014-4130/MS14-056）の悪用を試みたり、AdobeFlashの脆弱性（CVE-2015-5122、CVE-2015-5119、CVE-2015-3113など）を悪用するSWFファイルや、WindowsのTrueTypeフォント解析の脆弱性（CVE-2015-1671）を悪用するXAPファイルなどの実行を試みたりします（図-20）。これらのExploitコンテンツも難読化されており、表層的な解析では内容を把握することが困難です（図-21、図-22）。

ペイロード

Infectorの変遷

Landing pageやペイロードをホストするサーバ（Infector）は短い期間で使い捨てられています。2015年7月1日から28日の期間に、IIJは102個のIPアドレスをAnglerのInfectorとして確認しましたが、個々のIPアドレスの平均生存期間(同じ攻撃に利用され続ける期間)は約1.3日でした。なお、同時期のNuclearのInfectorは約1.6日なので、これはAnglerに限った傾向ではなさそうです。ただし、AnglerのInfectorのIPアドレスを管理しているAS（※50）には偏りがあり、前述の102個のInfectorは10個のASに集約され、更に全体の4分の3以上が上位2つのASに属しています（図-24）。Nuclearにも同様の傾向はありますが、Anglerに比べると多くのASに分散しているといえます（図-25）。また、AnglerがInfectorに利用するFQDNはIPアドレスよりも更に短時間で変更されます。IIJの観測では、個々のFQDNのAレコードが30分で削除され、そのドメインが使い捨てられていることを確認しています。このため、IPアドレスやFQDNのブラックリストによる対策が効果を発揮しづらくなっています（※51）。

対策

企業などの組織ネットワークにおけるドライブバイダウンロード対策としては、クライアント環境での適切なパッチ管理やプログラム実行可能領域の制限、EMETなどの脆弱性攻撃対策機能の有効化、Webブラウザプラグインの「Click to Play」の有効化などが挙げられます（※52）。HTTP Proxyを強制し、アクセスログを保管しておくことも、被害の緩和や早期発見に有用です。また、前述のFQDNの生存時間が短いという特徴を逆用して、例えばアクセスログから比較的アクセス数の少ないFQDNを抽出し、数十分後にそれらのAレコードの存在を確認するようなオペレーションを行えば、アクセスログの中からInfectorノードを抽出できる可能性があります。

Webサイト運営者、管理者の立場では、Webアプリケーションやコンテンツの厳格な管理が重要です（※53）。更に、前述のようにInfectorが一部のASに偏っている点を鑑み、サイトの運営環境（PaaSやIaaS、あるいはホスティング事業者など）についても、外部のブラックリストなどに登録されていないかなどの調査を行っておくことを推奨します。

FIDO Alliance の動き

FIDO（Fast IDentity Online）Alliance（※56）は従来よりも利便性が高く、より安全なログイン方法に関するオープンな標準化の策定を目指している非営利団体であり、2012年6月に設立されています。FIDO仕様では、オンライン認証はオフライン処理とオンライン処理の2つを組み合わせることで実現されています。従来から利用されているパスワード認証はオンライン処理のみで行われていると考えると理解しやすくなります。オンライン処理では、ユーザ（Prover）からサーバ（Verifier）にIDなどと共にパスワードが送信されています。このとき、パスワードはTLSなどの安全なチャネルを確保した上で送信する必要があり、別の安全なチャネルを利用しないケースではパスワードが簡単に第三者によって傍受されてしまいます。FIDO仕様では認証に関する通信をセキュアなチャネルを通して行わなくてもよいように、公開鍵暗号を用いたチャレンジ＆レスポンスによる認証（※57）をオンライン処理で行っています。一方でオフライン処理ではFIDO準拠デバイスがユーザをローカルで認証しており、ローカル認証に成功すると前述の公開鍵暗号認証で用いる秘密鍵の利用をユーザに許可する仕組みとなっています。オンライン処理の部分だけに注目すると、公開鍵暗号を用いたチャレンジ＆レスポンスによる認証という単純なプロトコルになっているため、生体認証を含む様々なローカル認証をサポートすることが容易で、拡張性が高い点からFIDOへの注目と期待が集まっています。

FIDO Allianceでは現在大きく分けて2つの仕様が策定されています。UAF（Universal Authentication Framework）標準は生体認証（バイオメトリクス認証）を、U2F（Universal 2nd Factor）標準は多要素認証（※58）を取り扱っています。前者のUAF標準については、2015年5月、NTTドコモがFIDO Allianceへボードメンバーとして加入し（※59）、同時にUAF標準を実装した2製品がFIDO準拠（FIDO Certified）として認定されています（※60）。これらのスマートフォンは虹彩認証や指紋認証が搭載されており（※61）、パスワードレスでのログインによる利便性が謳われています。また、多要素認証に関するU2F標準としてはGoogleLogin Service（※62）がFIDO準拠リストに挙げられています。2段階認証プロセスでのセキュリティキー（※63）の1つとしてU2F標準のUSBデバイスが利用可能となっており、国内でも複数の代理店から販売されています。現在、Google Chromeバージョン40以降のブラウザでのみ利用可能ですが、Microsoft社も次期OSであるWindows10での対応を表明しており（※64）、利用が拡大すると予想されます。また、F2F標準はNFCやBluetooth経由での利用について拡張されるとのアナウンスもありました（※65）。更に6月には米国政府システムにおけるセキュリティ標準化仕様を策定しているNISTや英国内閣組織がFIDO Allianceへ加入しており（※66）、政府機関での利用も検討されていると考えることができます。NISTからはInteragencyReportとしてスマートカードを利用した多要素認証に関するレポートのドラフトが7月に公開されました（※67）。

ワンタイムパスワードの利用

オンラインゲームにおいて、仮想通貨や仮想アイテムを狙った不正ログインが相次いだことから、パスワード認証ではなく、スマートフォンなどの他のデバイスと連動したワンタイムパスワード利用への移行が推奨されました（※68）。その際、ワンタイムパスワードの利用者に、ゲーム中で利用されるアイテムの増強などのボーナスを与えるといった、利用拡大のための独自の施策がとられています。更に不正ログインの被害が確認された場合には、できる限りのデータ救済措置が取られるというサービスも見受けられます。

また、オンラインバンキングにおいてもワンタイムパスワードの利用が広がっています。オンラインバンキングへのログインでは、従来は通常のパスワードもしくは暗証番号を用いた認証が行われることが一般的でした。ログイン中に振込などの重要なトランザクションが行われる際には、これまで乱数表が書かれたカードを書留などで安全に郵送した上で、トランザクションごとに異なる組み合わせの乱数（パスワード）を入力させる利用者認証を行っていました。この乱数表カードの利用には、もし攻撃者に内容を傍受されていた場合には、多数のトランザクションを行うことで徐々に乱数表の内容が漏れてしまう問題がありました。このため、乱数表に書かれたパスワードだけでなく、カード発行日を入力させるなどで、安全性を補う試みが行われています。しかしそこには限界があるため、一定時間ごとにパスワードが自動的に変更される専用デバイスへの切り替えが行われました。その後、入力インタフェースを持つ専用デバイスが利用されるようになりました。専用デバイスでは入力とトランザクションを結びつけることができ、例えば振込先の口座番号を入力させることでより安全な認証を行う方式へと変化しています。現在、このトランザクション認証は一部の銀行でしか対応していませんが、他銀行でも同じ専用デバイスが用いられているため、今後対応することが予想されます。

更に、専用デバイスやスマートフォンのアプリを用いたワンタイムパスワードではなく、デバイス不要のワンタイムパスワードの利用も広がっています。前者・後者共に同じ用語が用いられていますが、概念が異なります。まず利用者はメールアドレスやショートメッセージを受け取れることが前提となります。通常のパスワードによるログインを行うと、短時間だけ利用可能なトークン（ワンタイムパスワード）がサーバでランダムに生成され、メールやショートメッセージを介して送信されます。ユーザがそれを受け取り、サーバに送信することで認証が完了する仕組みです。インターネットと携帯電話網の両方を利用するなど、ログインで利用したチャネルとワンタイムパスワードの受信に利用したチャネルを分けることで、両者を同時に傍受されない限りはより安全性を確保できるメリットがあります。また専用デバイスを利用しないため、比較的コストの安いシステム運用が可能となります。オリジナルパスワードを守るために、それぞれのスマートフォンなどのデバイスで、一時的に利用するだけのためのパスワードを割り振るという観点では派生パスワードと考えることもできます。

ソーシャルログイン

加えて、ソーシャルログインと呼ばれる手段を提供するサイトも増えつつあります。あるリソースを提供するサーバで独自にID・パスワード管理を行わず、SNSやポータルサイトをIdPとして利用する、つまりユーザ認証手段としてのみ利用して認証を行うものです。新しいサーバの利用時にユーザが既に利用しているサーバとの連携許可を与えることで、新しいサーバにユーザ登録を行うことなくログインすることが可能となる方式です。これは、サーバ・ユーザ双方で新しいパスワードを管理する必要がなくなるというメリットがあります。しかし、これまである特定のSNS内など限られた範囲で利用していたIDで、新たなサーバとの連携を許可する際には、連携を行ったサーバ間での情報の流通に留意する必要があります。

情報収集などの目的で過分な情報を参照しようとするサーバが存在しますし、悪意のあるサーバと連携したために、SNS上で不要なメッセージを発出される事件なども発生しています。また、本来ならば異なるレルムの異なるIDでそれぞれ実施していた独立の活動が、連携したサーバ間でやり取りされる情報に基づいて、同一人物による行動として結び付けられてしまう可能性があります。このため、ログイン中に別のエンティティ（派生ID）として立ち振る舞うようIDを切り替える機能を活用したり、あるサーバの利用を終えた時に確実に連係を解除する手続きを行うなど、利用者側での慎重な対応が必要となる場合があります。

リスクベース認証

最後にリスクベース認証について紹介します。今年7月、主要サービスにおけるパスワード管理に関する実態調査（※69）が総務省から発表されました。パスワード設定が可能な文字や文字数制限、パスワード管理時にハッシュ化しているかなどに加え、同一IPアドレスからのログイン試行に関連する項目についても調査が行われました。認証時に普段とは異なる振る舞いをする、例えばありえない国外からのログインなど、普段のユーザの利用環境との違いを検知し、IDをロック（一時的にIDを無効化）したり、普段のパスワード認証に加え他の認証を行う多要素認証を実施したりするケースがしばしば見られるようになりました。ユーザに対して常に多要素認証を強要したりするなど一方的に利便性を損ねるのではなく、サーバがユーザの挙動の違いを自動的に検知した場合にのみ、今後起こりうる「リスク」を配慮し、より強固な認証方式の利用にシフトするという、利用者の利便性に配慮した中間的な認証方式も実際に利用されはじめています。

このように認証に関する状況は、利用者の利便性とリスクを考慮してトータルコストを最適化する方向にあります。認証を行う対象となるユーザの情報リテラシに応じて、トータルコストは変化しますから、その組織ごとの最適方式を見つける必要があるでしょう。またユーザは固定されておらず、常に増減していることから、状況に応じた見直しが求められます。