空腹

空腹を満たすためいろいろなものに、食いつこう

セキュリティ対策“最後の砦”、「サンドボックス」とは何か

2014-02-28 17:53:33 | 日記
セキュリティ対策“最後の砦”、「サンドボックス」とは何か という記事を見つけました

 標的型攻撃は、IT/非IT問わず、さまざまな攻撃技術を組み合わせて機密情報や個人情報の窃取を狙い、多くの企業IT担当者を悩ませている。標的型攻撃の特徴は、ターゲットとなる組織に合わせてマルウェアを用意することにある。

 マルウェアは近年、急速にコモディティ化が進み、例えば既存マルウェアの亜種であれば、高度なスキルがなくても簡単に作成できるようになった。そのため、シグネチャ型の対策では検知が難しい「未知の攻撃」を仕掛けることも容易になっている。

 こうした中、セキュリティベンダーが相次いで市場投入しているのが、「サンドボックス」という技術を用いたセキュリティ製品だ。ガートナー ジャパン リサーチ部門 ITインフラストラクチャ&セキュリティ セキュリティ担当 リサーチ ディレクターの石橋正彦氏に、サンドボックス型セキュリティ対策製品のニーズや市場動向について話を聞いた。

 サンドボックスは、サーバ仮想化でおなじみの仮想化技術を用いるセキュリティ技術だ。実環境に影響を及ぼさない仮想環境で、疑わしいソフトウェアやファイルの“振る舞い”を実際に確認し、シグネチャでは検知できない未知のマルウェアを検知する。

普及状況:日本では黎明期のさらに前段階

 「ガートナーは“サンドボックス”という呼び名を使っておらず、当社が2012年に定義した『Advanced Thread Detection(ATD)』の一部だと認識している」と、石橋氏は説明する。まだ登場したばかりの技術・製品であるため、まだ定義中だというのが正直なところだ。とはいえ、「国内市場ではサンドボックスという名称が浸透しており、多くのベンダーがこの名を使っている」(石橋氏)。

 サンドボックス型セキュリティ対策製品は、米FireEyeのアプライアンス「FireEye Malware Protection System」によって日の目を見た。すぐ後を追って米Palo Alto Networksが製品を投入。その後、国内ベンダーのFFRIやファイアウォールの老舗であるイスラエルのCheck Point Software Technologiesが続き、米McAfee、トレンドマイクロ、米Fortinet、米Websenseらが、2013年に相次いでサンドボックス型製品を提供している。

 もともとFireEyeの技術は、「米国政府が軍事用に開発させて、民間に応用したものだった」(石橋氏)という。「登場当初は、『日本では売りにくいのではないか』と考えたが、徐々に浸透して市場に受け入れられていった」と石橋氏は説明する。

 各社がサンドボックスを次々と投入したのはなぜか。石橋氏は、「FireEyeがサンドボックスの技術を可視化し、ユーザー企業へ詳しく説明したことにある」と推測する。

 サンドボックスの技術自体は、仮想化技術を用いてクライアントPC環境を構築し、そこでマルウェアを実際に稼働させるという単純な仕組みだ。「もともとセキュリティベンダー各社は、自社のセキュリティ研究組織で仮想化技術を活用し、マルウェアや攻撃を検証していたと考えられる。ただし、その技術を公にすることはなかった。FireEyeの成功を見て、こうした技術を慌てて製品化し、市場に投入してきたというのが実際のところだろう」(石橋氏)

 ただし、主要なセキュリティベンダーである米Symantecは、現時点では「サンドボックス」と称する製品を提供していない。

登場の背景:“グレーゾーン”を減らす最終防衛ラインとしてニーズが高まる

 サンドボックス技術は、マルウェア/スパム対策の“誤検知問題”を解決する手段としてニーズが高まった。

 一般的なマルウェア/スパム対策製品は、技術的には97~98%もの高い検知率を達成している。問題は、その高い誤検知率の“副作用”が、ビジネスに大きな影響を与えるところにある。マルウェア/スパム対策の検知率を高めると、正常なメールやファイルまでもが悪意のあるものとして判断されることがあるからだ。

 こうした誤検知で重要なファイルやビジネスメールまでも遮断してしまう状況を避けるため、セキュリティベンダーは、“黒”(悪意のある)と“白”(正常な)の中間となる「グレー」という判定指針を設けた。完全に黒だといえないものについては、ユーザーに判断を任せるというスタンスである。

 「誤検知の問題は、10年以上も画期的な解決策がない状況だった。現状では、検知率をあえて60%程度にし、20~30%をグレーだと判断するマルウェア/スパム対策製品も珍しくない」(石橋氏)

“グレー”の中から本物のマルウェア/スパムを見つけ出す

 ここで問題となるのが、「グレーと判断されたメールやファイルの中にマルウェアやスパムが含まれていても、人間には判断できないケースがあることだ」と、石橋氏は指摘する。

 メールを例にして考えてみよう。日常業務で使っているアプリケーションのベンダーをかたるスパムメールに、セキュリティアップデートを偽装したフィッシングサイトのURLが記載されていたとする。このURLがマルウェア/スパム対策製品のデータベースに存在していなければ検知は難しく、グレーと判断せざるを得ない。

 さらに、メール本文の内容が「ベンダーのメールだ」と判断してもおかしくないように精巧に作られていれば、間違ってクリックしてしまうユーザーも少なくないはずだ。結果としてフィッシングサイトへ誘導され、個人情報を詐取されたり、端末にマルウェアを仕込まれたりしてしまう。

 こうした手の込んだスパムやマルウェアを確実にチェックできるセキュリティ製品は「これまでなかった」と石橋氏は語る。サンドボックスは最後のチェック、つまりURLのクリックやファイルの実行といった作業を仮想環境で代行する。こうすることで、グレー判定のファイルやメールの中から、人手に頼らずにマルウェアやスパムを見つけ出すことができる、というわけだ。

 サンドボックスは、高度なサイバー攻撃を防ぐというよりは、「さまざまなセキュリティ製品の“チェック漏れ”をいかに拾うかに焦点を当てた技術だといえる」(石橋氏)。

提供形態:アプライアンスとオンラインサービスに大別

 サンドボックス製品の提供手法は、大きく2つに分けられる。仮想環境の動作環境をアプライアンスとして提供するか、オンラインサービスとして提供するかの違いだ。仮想環境でクライアントOSを稼働させ、ユーザーの代わりにマルウェアを稼働/感染させて挙動を見るというサンドボックスの基本的な仕組みは、いずれも同様である。

 アプライアンス型の場合、それなりにスペックの高いハードウェアを導入する必要がある。複数の仮想マシンを起動し、日々送られてくるマルウェアを継続的にチェックする必要があるからだ。

 一方のオンラインサービス型は、分析が必要なデータをセキュリティベンダーのデータセンターへ送り、ハイエンドな仮想環境で高速にチェックする仕組みである。ユーザー企業の拠点に設置するハードウェアは、比較的スペックが低くてもサンドボックスの性能が目立って低下することはない。ただし、重要なデータがデータセンターに送られる可能性は否定できない。

 「ヨーロッパでは一般的だが、組織によっては、規則で重要なデータを海外に持ち出せないケースもある。そのため、国内に閉じたシステムを好む企業もあるだろう」

ベンダーによって提供形態に差が

 上述した観点を踏まえた上で、代表的なサンドボックス製品を見ていこう。

 ファイア・アイの「FireEye Web Malware Protection System」「FireEye Email Malware Protection System」は、それぞれアプライアンス内に仮想環境を構築する。FFRIの「FFR tabaru」やトレンドマイクロの「Deep Discovery Advisor」も同様の仕組みを持つ。マカフィーの「McAfee Advanced Threat Defense」も同様だが、同社製品と組み合わせて導入する必要があり、単体で導入することはできない。

 サンドボックス機能をオンラインサービスとして提供しているベンダーは、パロアルトネットワークスやウェブセンス・ジャパン、チェック・ポイント・ソフトウェア・テクノロジーズ、フォーティネットジャパンと比較的多い。

 パロアルトネットワークスの「WildFire」は、同社の次世代ファイアウォール製品「PAシリーズ」と組み合わせて利用するオンラインサービスだ。国内ではNTTコミュニケーションズの国内データセンターにサンドボックスのシステムを設置してサービスを提供しているので、前述のように海外へのデータ転送が難しい企業や組織に適している。また、WildFireと同等の機能をオンプレミスで構築できるアプライアンス「WF-500」も提供する。

 ウェブセンス・ジャパンは、同社のゲートウェイセキュリティアプライアンス「Websense Web Security Gateway」の有償オプションとして、サンドボックス機能を持つオンラインサービス「Websense TRITON ThreatScope」を提供する。チェック・ポイントのサンドボックスサービス「Check Point ThreatCloud Emulation Service」は、単体での利用が可能な他、同社のゲートウェイセキュリティ製品で検出したファイルを転送して解析することもできる。

 フォーティネットジャパンは、アプライアンス型のサンドボックス製品である「FortiSandbox」に加え、同社の統合脅威管理(UTM)製品のファームウェア「FortiOS」の機能としてオンラインサービスを使ったサンドボックス機能を提供する。

製品選定ポイント:性能やDCの設置場所に注目

 サンドボックス製品の選定ポイントは、前述したように、アプライアンス型であればハードウェア性能、オンラインサービス型であれば運用基盤となるデータセンターの設置場所、ということになる。

 アプライアンス型については、「安価なアプライアンス製品を導入したところ、ネットワーク速度の明らかな低下を体感したために、性能の高いモデルに取り換えた事例もある」と石橋氏は指摘する。一方のオンラインサービス型については、「重要なデータを扱うユーザー企業は、国内データセンターを使用するWildFireのように、海外にデータを転送しないサービスが適する」(石橋氏)。

 サンドボックス製品は、これまでのゲートウェイセキュリティ製品を置き換えるものではなく、エンドポイントの間近で検出漏れを防ぐ、いわば“最終防衛ライン”である。一般的にサンドボックス製品は高額であるため、予算に応じてミッションクリティカルな部門から導入を始めるのもよい。

 「サンドボックスは国内において、“黎明期”にも入っていない登場したばかりの技術/製品だ。市場が形成されていくのは、2014年後半から2015年にかけてのこととなるだろう」と石橋氏は予測する。

 マルウェアによっては、サンドボックスなどの特殊な環境で稼働していることを認識し、動作を停止するものも報告されている。サンドボックスベンダーがこうしたマルウェアへの対処を進めることで、安全性はより高まると考えられる。

 NTTコミュニケーションズのように、サンドボックス機能をマネージドサービスの1つとして提供するケースも登場しており、今後、導入の選択肢は増えていくはずだ。脅威の状況と製品の成熟度をしっかりと見据えて、効果的な導入を検討したいものである。

 課題は興味があったが 内容は漠然としている 

ビットコインのMt.Goxがアクセス不能──大手6社が共同声明

2014-02-26 19:48:25 | 日記
ビットコインのMt.Goxがアクセス不能──大手6社が共同声明 という記事を見つけました

 2月7日からビットコインの引き出しを停止していた取引所のMt.Gox(マウントゴックス)のWebサイトが日本時間の25日午後3時半ごろからアクセス不能になっている。URLを入力するとブランクページが表示される。

【UPDATE】日本時間の26日午前4時ごろ、Mt.GoxのWebサイトに「Mt.Goxの運営と市場に関する最近の報道とその影響を考慮し、サイトと顧客を守るために当面すべての取引を停止することを決定しました。状況を詳細に監視し、対処します」というメッセージが掲載された。

 Mt.Goxのサイトがアクセス不能になる前、ビットコインウォレットの米Coinbaseが公式ブログで関連企業5社との共同声明を発表した。

 「Mt.Goxに関する共同声明」と題したこの発表文には「Mt.Goxがユーザーの信頼を裏切ったのは、Mt.Goxという1社だけの行為の結果であり、ビットコインの復活力や価値、デジタル通貨業界には影響しない」とし、Coinbase、Kraken、BitStamp、Blockchain.info、Circle、BTC Chinaの6社は「Mt.Goxの失敗で失われてしまったビットコインへの信頼を回復するために、共同でビットコインの将来と顧客のファンドの安全を守る」と宣言した。

 その一環として、6社は向こう数日中に顧客のすべてのファンドが安全に運営されていることを説明するという。

 Mt.Goxは7日に「技術的な問題から」引き出しを停止し、17日に「間もなく」引き出しを再開すると発表していた。米Reutersによると、少なくとも3カ所のオンライン取引所がサイバー攻撃を受け、停止したが、Mt.Gox以外はその後復旧した。

 Mt.Goxは2月23日にBitcoin Foundationから脱会している。

 声明文にはMt.Goxの現状については説明はなく、「どんな産業にもいえることだが、黎明期には必ず駆逐すべきトラブルメーカーがいるものだ。Mt.Goxはビットコインコミュニティーのメンバーとの非公式な討議で問題を認めた」とのみ書かれている。

 ScribdにリークされたMt.Goxの文書によると、過去数年の間に74万4408のビットコインが盗まれていた。Coinbaseによる本稿執筆現在のレート(1ビットコイン=5万1914.44円)で換算すると約390億円に上る。

 このまま閉鎖すると大損害する人が出るのでは?

危険なWeb攻撃から身を守る「Webアプリケーションファイアウォール(WAF)」の全て

2014-02-24 18:01:27 | 日記
危険なWeb攻撃から身を守る「Webアプリケーションファイアウォール(WAF)」の全て という記事を見つけました

今更聞けない、「WAF」とは何か

 今やインターネットを介したサイバー攻撃の大半がWebを標的にしている。このことから、WebサイトやWebアプリケーションの保護に特化したセキュリティ製品であるWAFに対する認知度が急速に高まっている。

 認知度は向上しているものの、従来型のネットワークセキュリティ製品と比較して、具体的に機能レベルでどのような差異があるのかについては、意外と知られていない。また一部同様の機能を持つ「次世代型ファイアウォール」と混同されるケースも多いのが現状だ。WAFとは何かについて、ここで整理しておこう。


WAFに求められる機能

 機能面で見ると、WAFに分類される製品は、以下のような機能を特に備えるものとして捉えることができる。

HTTP解析機能

 WAFの中心的な機能がHTTP解析機能だ。この機能を理解するために、HTTPによる通信の仕組みを簡単に説明していこう。

 Webアプリケーションと、Webブラウザなどのクライアントとの通信は、一対のクライアントからの通信要求である「リクエスト」と、Webアプリケーションからの応答である「レスポンス」が多数発生することで成り立っている。

 インターネットのプロトコル仕様を記載したRFCでは、クライアントからのリクエストは「URL」と「送信データ(パラメータ)」を含み、「GET」「POST」などのコマンドを使うといった、データの送信手順が定められている。Webアプリケーションやクライアントは、RFCが定めるこうした手順に従って、データを送受信している。

 データの送受信時には、ヘッダ情報も合わせて送信される。特に重要なヘッダ情報として、要求の転送元を示す「referrer」、サーバ側から割り当てられた情報を保持する「cookie」などがある。

 サーバからの応答レスポンスに必ず含まれるのが「レスポンスコード」だ。レスポンスコードは、リクエスト要求が成功したかどうか、また失敗した理由などを判断する材料を提供する。

 膨大なトラフィックの中から、リクエストやレスポンスを識別して論理的に理解する――。これがWAFの最も基本的な処理内容である。

SSL復号機能

 Webでは、重要な情報を含むデータの送受信にはSSL暗号化を利用することが一般的であり、トラフィックをそのまま解析しても、送受信データの中身を識別できない。

 WAFの配置方法に目を向けると、
•WAFをL2ブリッジとして動作させ、既存環境に透過的に設置する「透過モード」
•外部からのTCPセッションを一度WAFで終端し、別セッションでWebサーバと通信する「リバースプロキシモード」
•L2/L3スイッチのモニターポート(監視用ポート)に接続する「スニフィングモード」

など複数ある。どの配置方法を取るにしても、性能を落とさずにSSL通信の復号や解析ができることが必須要件である。

ユーザーセッション追跡機能

 HTTPでは、上述したcookieという識別子をリクエストに付与することで、個別のユーザーセッションの状態を保持できる。最近は、こうしたセッション管理の仕組みを悪用する「クロスサイトリクエストフォージェリ(CSRF)」「セッションフィクセーション」といった攻撃が盛んだ。こうした中、WAFにはHTTPのユーザーセッションを追跡する機能が求められている。

ブラックリスト検知、シグネチャ更新機能

 連載第2回「“危ないWebアプリ”を生む『既存コードの脆弱性』の怖さ」で紹介した、CMSの既知の脆弱性を狙った攻撃を防御するには、シグネチャを利用した「ブラックリスト検知」が非常に有効だ。脆弱性は日々新しいものが報告されるので、シグネチャの更新頻度は高い方が望ましい。

学習によるホワイトリスト機能

 Webアプリケーションの構造はWebサイトによって異なる。そのため、画一的な防御の仕組みでは攻撃に対処できない場合も多い。そのため、各Webアプリケーションが日常的に利用するURLやパラメータを学習し、通常のWebアプリケーション利用から逸脱した疑わしいアクセスを遮断できるホワイトリスト機能が重要になる。

相関分析機能

 Web攻撃はますます巧妙化しており、セキュリティ対策製品による検知を回避する手法も確立している。上述したブラックリスト検知などの単一の検知手段だけで判断するのではなく、複数の検知手段で得た検知結果の相関をとり、総合的に危険度を判断する仕組みが重要だ。

カスタムポリシー作成機能

 連載第4回「“パスワード使い回し”を悲劇に変える『アカウントリスト型攻撃』とは」で紹介したように、アカウントリスト型攻撃などをブロックする手段として有効なのが、カスタムポリシーの作成機能だ。時間によって制御のしきい値を変えたり、発信元のアドレスやURL/パラメータなどの制御条件を柔軟に変更できることが望ましい。

レピュテーション機能

 IPアドレスや地理情報といったリクエストの発信元情報は、攻撃を判断する際の重要な情報となる。ただし、匿名プロキシや踏み台となるボットサーバなどを経由して発信元を隠蔽し、攻撃源の特定を難しくすることは多くの攻撃で見られる。こうした手法に対抗する万能な手法はないが、過去の実績や第三者情報を利用したレピュテーションによって判断する方法が有効だ。

 上述した全ての機能は、本連載で特に紹介してきた最新の脅威の防御において重要な役割を果たす。他のゲートウェイ/ネットワークセキュリティ製品と比較しても、アプリケーション層の防御においてWAFは全般的な強みを発揮し、かつ柔軟なカスタマイズも可能なのが強みだ。特に、HTTP解析機能やユーザーセッション追跡機能は、アプリケーション層の防御に焦点を当てたWAFならではの機能だといえる。

WAFの選定ポイント

 セキュリティ製品を比較する際に広く用いられているのが、脆弱性攻撃の「検知率」や脆弱性の「カバー率」といった指標である。既存の脆弱性にどの程度対処できるか、公開された脆弱性への対応スピードが速いかどうかなどを測るために利用する。

 こうした指標を基にした比較は、WAF製品の選定に当たっては必ずしも適切ではない。高い検知率は、逆に高い誤検知率にもつながり、正常な通信を止めてしまう可能性があるからだ。Webアプリケーションの攻撃手法は比較的高度で複雑であり、1つの脆弱性を狙う攻撃手法が多数存在する場合もあることが背景にある。

 WAFの検知率や誤検知率を評価するためには、Webサーバに対して診断ツールを仕掛けるだけでは難しく、検知率などのカタログ値に惑わされないようにしたい。できる限り公平にWAFの能力を評価する方法として、以下が挙げられる。

実環境における検証

 自社のWebサイトのトラフィックを検査できる箇所にWAFを試験導入し、一定期間の動作確認をすることで、攻撃検知能力や正常トラフィックの処理を確認できる。実環境に導入する場合には、上述したスニフィングモードで導入ができるWAF製品があれば、運用中のWebサイトに影響を与えずにテストできる。

業界団体作成のWAF評価基準書

 Webアプリケーションセキュリティに関する業界団体「Web Application Security Consortium(WASC)」が複数のWAFベンダーの意見を集約し、WAFの評価基準書「Web Application Firewall Evaluation Criteria(WAFEC)」を作成している。WAFに求められるさまざまな要件が網羅されているので、製品を比較する際の参考になるだろう。

WAF専用の評価ツール

 Impervaの「WAF Testing Framework」など、高度なアプリケーション攻撃からWebサイトが守られていることを検証するための評価ツールも登場し始めている。こうした専用ツールの特徴は、誤検知および検知漏れの双方の指標でWAFを評価可能なことだ。攻撃を防御できるかどうかという視点だけではなく、攻撃と誤認しやすい正常なトラフィックもシミュレーションできるからである。

WAFの提供パターンはさまざま

 現在、さまざまなタイプのWAF製品/サービスが存在する。提供形態で分類すると、(A)専用アプライアンスをネットワークに設置する「オンプレミス型」、(B)WebサービスとしてWAFを提供する「クラウド型」に大きく分類できる。それぞれの特徴を以下にまとめた。


 高度な利用方法として、オンプレミス型とクラウド型双方のいいとこ取りをした「ハイブリッド型」で利用するケースもある。大量のネットワーク/サーバリソースを占有するDDoS攻撃の対策を例に取ってみよう。トラフィック全体をクラウド型のWAFでいったんフィルタリングすることで、DDoS攻撃のトラフィックを自社サイトの外部で止めることが可能となる。その上で、オンプレミス型のWAFは、より綿密にカスタマイズしたポリシーで運用し、多層的な防御を実施できる。


 6回の連載を通して、Webアプリケーションに関する脅威のトレンドや対策法を紹介してきた。Webアプリケーションは今後もますます発展していくだろう。利便性と安全性は常にトレードオフの関係にある。「ユーザーにとっていかに便利なシステムを作るか」という議論はもちろん重要だが、セキュリティについても同じぐらいの時間を費やして議論しなければならない。本連載が、今後のWebアプリケーションセキュリティ対策を検討する一助となれば幸いである。

 果たして公平な評価ツールはあるのだろうか 未知のウイルスが相手なのだから