スキャンエンジンが1980年代の原始的なシグニチャベースの祖先から、どのようにして現在へと進化してきたかについて、つい先日記事を投稿した。マルウェアやエクスプロイトのような脅威からエンドポイントを保護するに至り、ファイルスキャン自体はパズルの小さなピースに過ぎなくなった。当該記事ではその背景に触れた。そして本日、私はビヘイビアエンジン、別名HIPS(host-based intrusion prevention system)に焦点を合わせる。
平たく言うと、ビヘイビアエンジンは悪意がある可能性を有するアクションについて、システム上のプロセスの実行を監視することで機能する。もし1つまたは一連の、悪意のあるアクションを見つけたら、そのプロセスは停止される。これにより、悪意のあるペイロードが目的を達成することが絶対にないように徹底する。
ビヘイビアの監視ではマルウェアの実行ファイルをブロックするのに加えて、Webベースの弱点を突く試みを阻止し、OfficeのマクロやPDFのような非PE(Portable Excutable)形式のマルウェア感染ベクターをブロックするためにも使われ得る。これは、Webブラウザや、文書のビューワやエディタのような一般的なアプリケーションを監視することによって実現される。
たとえば、もしユーザが悪意のあるサイトに訪れたとき、ビヘイビアの監視によりブラウザのプロセスそのものに弱点を突くような試みがあるという兆候を掴んだら、不正利用が始まる前に当該プロセスを停止する。蓋を開けてみると、これはゼロデイの攻撃を阻止するのにうってつけの方法であった。
それで、なんでビヘイビアエンジンがこんなに便利なのか、って?真相はこうだ。悪意のあるペイロードの大多数が、システムを感染させるために、数は少ないながら一切合切同じトリック群を使っているのだ。Excelファイルが実行ファイルやシェルコードをディスクに書き込んだり、システム上の実行コードを起動したりしようとしたら、これは悪意があるのにまず間違いない、と考えられる。この種のビヘイビアは正当な文書ではまったくもって聞いたことがない。
ビヘイビアに応じてブロックするということは、サンプルがどのように「見える」かを意識する必要がない点ですばらしい。シグニチャベースでスキャンするやり方を回避する目的で、新しいマルウェアが次々と公開される。しかし、このようにバージョンが異なる場合でも、依然として同一のアクションを実施する。ビヘイビアに基づき最初の1つを検知したら、以降のものも検知することになる。
マルウェア作者がビヘイビア上のルールを回避できる手段は、新たなアクション群を携えて登場することだけだ。そして新たな感染ベクターが非常に高い頻度で出現することはない。その理由として、大半の場合、新たなマルウェアやエクスプロイトが表面化したときには、我々はすでに当社のビヘイビアエンジンでそれをカバーしている、ということが挙げられる。マルウェアの作者たちが一定期間使用を続けてきたトリックは、これからも継続して使われる可能性が高い。
しかしながらクライアントサイドでのビヘイビアの監視は、警告抜きでは実施できない。監視するプロセスはいずれも、パフォーマンスに軽微な影響を与える。この理由により、監視する対象を制限することは重要である。これはいくつかの方法で実現できる。
ホワイトリストはスキャンをすべてスキップできる簡単かつ迅速な方法である。それゆえにエンドポイント保護ソフトウェアでは、その他の分析ステップに先立って、ホワイトリストの確認を行うことは珍しくない。サンプルの暗号学的ハッシュのようなシンプルなメタデータや、あるいは署名付き証明書のようなより複雑なメタデータを基に、ファイルをホワイトリストに登録できる。
スキャンエンジンは一般にビヘイビアエンジンよりも高速である。したがって、ファイルが実行される前に(たとえばファイルがディスクに書き込まれるときや、ネットワーク経由で到着したときなどに)悪意があるか否かを判定するためにスキャンエンジンが使えるのであれば、パフォーマンスの小幅な改善が得られる。
人間に例えて、以上すべてがどのように動作するのかを明らかにしよう。
ある企業の警備隊には、社屋の物理面での安全を監視する任務がある。大半の時間は、ずらりと並んだ監視カメラからの映像をモニターすることに費やしている。警備員の一部は交替で社屋を見回る。
一日を通じて、社屋への出入りがある。従業員の大半は見えるようにIDカードを身に付けている。一部の従業員は警備員に知られてさえいる。この例えでは、こうしたIDを身に付けた従業員がホワイトリスト上のサンプルに相当する。警備員はこのような従業員にはたいして注意を払う必要はない。なぜなら「良い人」だと分かっているからだ。
また訪問者も一日中、出たり入ったりする。新たにやって来る客たちについて、警備員は知らない。訪問者は受付で同伴者を待って、さらに奥へ行く前に一時的なIDカードを保持するように案内される。構内にいる間、訪問者には常に従業員が付き添っている必要がある。記名して一時的なIDを得るという、従業員と会うプロセスは、大まかに言ってスキャンエンジンにかけられるサンプルに例えられる。スキャンエンジンは「良い人」かどうかは判別が付かないが、たぶん悪意がないことは分かる。
今回の仮定の状況において、午後のある時点で、手続きを踏まなかった人がやって来たとする。従業員が全員忘れずにIDカードを身に付けているとは限らないので、来たのは従業員なのかもしれない。しかし警備員の誰も、彼の顔に見覚えがない。到着後まもなく、この未知の訪問者は受付を通り過ぎ、ある従業員の背後にぴったりとついて本館へと達した。警備員は直ちにこの振る舞い(ビヘイビア)に気付き、監視カメラの映像を通じて彼を監視している。また見回り中の警備員の1人に連絡をして、未知の訪問者のいる場所へ向かわせた。このステップは、ビヘイビアの監視を始めることに例えられる。
この訪問者の振る舞いを警備員が引き続き厳しく監視している中で、彼が社屋の廊下を歩き、ついに立ち止まってバックパックからバールを取り出し、会社のサーバルームの一室を開けようとしているのを観察した。この時点で、警備員が現場に現れ、サーバルームに接近するのを阻んだ。
1つの行動によって、ある脅威が実際に悪意のあるものかどうかを判別するのに十分なときばかりではない。一連の行動、今回の場合には同伴者なしで本館へ通り抜け、施錠されている部屋へ押し入ろうとしたことが、最終的に行動を取るように導く、一連の指標となった。
クライアントサイドでのビヘイビアの監視は、一般的なマルウェアやエクスプロイトからシステムを保護するのにもっとも効率的な方法の1つだが、バックエンドでのビヘイビア分析は、また別の強力なツールをもたらす。
クラウドコンピューティングのインフラを用いると、計測器付きのサンドボックスを同時に数千起動できる。ファイルやURLがこうしたサンドボックスへ送り込まれて実行される。個々に起動して、実行中に発生したことに基づいてメタデータを生成する。こうしたメタデータには、サンプルが実行されているシステムに対する変更と、サンプルそのものを実行した痕跡の双方が含まれ得る。続いて、この得られたメタデータは、一連のルールエンジンによって疑わしいビヘイビアがないか分析される。サンプルはさらなる分析のためのフラグが立てられ、多くのケースでは、自動的にオンザフライで検知が生成される。
バックエンドのサンドボックスを活用することで、1日当たり数十万件のファイルやURLを分析できる。手作業で行うのはほぼ不可能な件数だ。このプロセスにより、自動的な静的分析のプロセスと合わせて、サンプルのカテゴリー化やグループ化が容易に行えるようになる。
クライアント自体あるいはバックエンドのいずれで用いられるにせよ、ビヘイビアの監視は悪意のある脅威からシステムを保護する強力なツールである。ビヘイビアの監視技術はある状況においてエンドポイントで実施されるに至る。この状況とは、システムがどのように脅威と遭遇したのかによる。これまで説明してきたとおりビヘイビアによるブロックは、悪意のあるサイトを訪れ、悪意のあるドキュメントを開いたり、悪意のある実行ファイルを起動したりしたときに(アクション!)始動する。この理由により、VirusTotalのスキャンレポートではこの種の結果を確認できない。ビヘイビアによるブロックが要因となり、当社製品が現実世界の状況下でどれくらいうまくいっているのかを確認したいのであれば、AV-ComparativesやAV-Testでのテスト結果をチェックするとよい。
当社のHIPS技術がどのように動作するかについて、より技術的な解説にご興味がおありなら、ホワイトペーパーを確認してほしい。