「マルウェア・標的型攻撃への対策に、本当に必要なインターネット分離」第3回

前回は、以下を整理しました。

何を守りたいか
機密情報の配置と、マルウェアの到達範囲
インターネット分離に求められる画面転送方式

機密情報の定義と、それを守るための方法を考えることができました。今回は何から守りたいかを整理しながら、「マルウェアの特性とインシデントレスポンス」について、考えていきたいと思います。

標的型攻撃・マルウェアとは何か?

機密情報を何から守りたいと問われれば、標的型攻撃やマルウェアから守りたいという回答が一般的でしょう。第1回でも触れましたが、マルウェアは一体どのような動きで情報窃取をおこなっているかを、以下のスライドを使いながら改めて振り返ってみましょう。

具体的には下記の順で情報漏えいされてしまっています。

WEBやメールを通じてゼロデイ攻撃
マルウェアに感染
システム把握
機密情報に到達
C&Cサーバへアクセス

WEBやメールといったエンドポイントであるPC端末にまで必ず通信を通さなければならないものを利用しているため、セキュリティソリューションの多重化によって、限りなくゼロに近づけることはできますが、ゼロにすることができません。

また、重要なポイントはゼロデイ攻撃がほとんどだということです。つまり、既にウィルスだと認識されているものをわざわざ送るのでは、攻撃の成功率は低いため、世に認知されていない新しいウィルスを、特定の標的のためだけに作成しているということです。ウィルスを定義ファイルなどで検知しているようなタイプのセキュリティソリューションでは、全く防御できないことになります。

つまり、「防御できない＝感染に気づけない」ということになります。感染に成功すると、機密情報にアクセスするために、システム把握をしようとします。最近の事例では、この感染から数時間レベルで情報漏えいまでおこなわれてしまっています。

まとめると以下のようになります。

セキュリティソリューションでゼロにできない
ゼロデイ攻撃のため、感染に気づけない
感染すると、システム把握をして、機密情報にたどりつくが、それも検知できない
数時間レベルで情報漏えいする事例が出てきている

このようなマルウェアに対して策を講じていかなければならないということです。

何を信じるか?

セキュリティ対策として実施される入口出口対策は多重構成が一般的です。これでマルウェアを100％防ぐことができると思うかが判断の分かれ目になります。もしマルウェアの侵入を完全に防ぐことができるのであれば、業務PCも業務サーバも感染することなく、機密情報も盗まれることはないでしょう。

しかし、残念ながら、今までマルウェアによって情報漏えいしている事例で、入口出口対策をしていなかったところがあるでしょうか。先にも述べたとおり、インターネットに接続する理由であるWEBやメールは、業務PCで行う業務になるため、100％を保証してくれる製品・ソリューションは皆無でしょう。逆に保証してくれるものがあれば、それを購入すればよいと思います。

つまり、どんな多重防御態勢を敷いて対策を施していてもやられているのが現状なのです。そして、信じていたものが突破された場合、侵入の検知ができません。検知ができないものは駆除もできず、情報漏えいしたかどうかもわからないわけです。多重防御体制というのはリスクを0に限りなく近づけることに意味はありますが、多重にすればするほど運用管理負荷もかさむため、どこかで折り合いをつけなければなりません。

セキュリティの世界における「インシデントレスポンス」

セキュリティにおいて、感染に気づいて、対策をすることを「インシデントレスポンス」と呼び、基本中の基本です。最近では、情報漏えいしたかどうかについて、報告（レポート）が求められるケースもほとんどです。

この3ステップにおいて、インシデント認知というのは、セキュリティ機器のアラートなどからマルウェアに感染したことに気づくということを意味します。レスポンスは、インシデントに応じて事前に定めた対応の実施を行います。たとえば、マルウェアに感染したPCのネットワークケーブルを抜くなどはレスポンスと言えるでしょう。レポートは、なぜ起きたか、今までどのような対策をしてきたか、何が情報漏えいしたか、再発防止策は何かといった内容を報告することになります。

しかし、ここで思い出していただきたいのですが、入口出口対策であるセキュリティ機器で、マルウェアに気づけるでしょうか。気付けるものであれば、とっくに駆除もできるはずです。感染に気づけないから困っていたわけです。

つまり、インシデント認知ができないのに、レスポンスもレポートも実行できるわけないのです。逆にインシデント認知できるのは、情報漏えいしていたと外部から指摘されたときかもしれません。ただ、残念ながらそれは情報漏洩済みと同義です。

リフレッシュ運用の課題

よくインターネット分離環境において、VDIのリフレッシュを定期的に行えば、マルウェアが消えるから問題ないのではと訊ねられるケースがあります。残念ながら、これは思考停止の方法です。先ほどの例に当てはめて考えてみれば当たり前の話です。

インシデントレスポンスが求められる中で、レスポンスしか実施していないということになります。何かわからないけど、何か起きるかもしれないから対策を打っておこうというものです。そのため、マルウェアに感染していたかどうかもわからなければ、何が情報漏えいしたかどうかもわからないという方法なのです。先ほどの例に挙げたとおり、マルウェアの感染からC&Cサーバまでのアクセスに数時間で実施されていることを考えると、とてもリフレッシュ運用では間に合わないことがお分かりいただけるかと思います。

現時点でのインシデントレスポンスのタイムライン

もう少しわかりやすくするために、実際に攻撃者側の情報漏えいまでの時間推移と、防御側の手法についてまとめた以下のスライドをご覧ください。

まずは攻撃者側の視点です。

攻撃者はゼロデイのマルウェアを利用して、標的型攻撃を仕掛けてきます。
しかしながら、多重防御のセキュリティソリューションでも防げないものが感染してしまう。
防げないということは、気づくこともできていない
一度PCに感染したマルウェアは、機密情報への通信を確立するために、システムを把握するためのスキャンを開始する
数時間～数日で機密情報を流出させることに成功する

これらに対応するために防御側はどのようなことをするのでしょうか。

セキュリティに関連するログを定常的に統合分析する
セキュリティアナリストが、常に怪しい挙動が発生していないか膨大なログを監視しておく

この方法の問題点は、下記です。

統合分析して怪しい挙動を見つけ出すことができるスキルのある人を24時間体制で雇う（確保と高コストが課題）
ログが膨大すぎて早期に見つけることができるか、確実に見つけることができるか

数時間レベルで情報漏えいしてしまうにも関わらず、上記のような運用体制では、マルウェアがC&Cサーバにアクセスする前に止めることができません。また、確実に気づけるとも言えないので、永遠に気づけず、機密情報を垂れ流しにしていることになりかねません。インシデントに気づけないので、レスポンスが打てない状況というのは、まさにこのことです。

情報漏えいをJPCERTや警察から指摘されることがインシデント認知になり、そのときには情報は既に漏洩済みになるわけです。さらに悪いことには、情報漏えいをしてしまった可能性がある場合には、報告が求められます。しかしながら、感染に気づけなかったものをどのように報告できるでしょうか。

やれることとしたら、過去の膨大なログに遡って調査をすることですが、いままで気づけなかったにも関わらず、後追いで気づけるかどうかも問題です。また、調査に時間がかかり、安全が確認できるまでの間、インターネットに接続できないなど、業務に大きく支障が出ることは間違いありません。

結局、感染原因と感染範囲がわからないので、全台の業務PCのデータを消去し、マルウェアをネットワークから除去することになりますが、こちらも業務停止時間が長引いてしまうことが容易に想像できます。また、業務PCはリフレッシュできるかもしれませんが、サーバ側はそう簡単にいきません。つまり、サーバ側まで感染が広がっていたとしたら、せっかく業務PCをクリーンな状態にしても、サーバ側からピンポン感染する可能性があり、マルウェアの完全な除去が難しいと考えられます。

「マルウェアへの対策に求められるインシデントレスポンスとは?」

ではこのような現状において、どのように対策すべきかを最終回である第4回目にお話したいと思います。ここまでで、なぜインターネット分離をしなければならず、守りたい情報を考慮した際に、検討していた対策では不十分ということが感じていらっしゃるのではないでしょうか。最終回では、多くの自治体で採用されたインシデントレスポンスのしくみについてお伝えします。