ノートン インサイト:セキュリティを犠牲にすることなくパフォーマンスを改善するソリューション

みなさん、こんにちは。シマンテック、カスタマプロダクツエンジニアリングチームのマネージャを務めております Kunal Karandikarand です。ノートン 2009 シリーズには、私たちチームが自信を持って開発した新機能、ノートン インサイトが搭載されています。これまでに、その機能のしくみや目的についてたくさんの質問をいただきました。また、ノートン インサイトを同等の他社技術を比較した記事もいくつか書かれていますが、正直なところこれらは決して「同等」ではなく、シマンテックの開発した新機能には及ばないものだと思います。そこで、この記事を通じてノートン インサイトに関する疑問や誤解を解消できればと考えています。フィードバックや質問がありましたら、下のコメント欄にご自由に書き込んでください。

 

そもそものはじまり

私たちエンジニアリングチームは、シマンテックのセキュリティ製品がシステム全体のパフォーマンスに与える影響を抑える方法について、数年前からブレーンストーミングを行ってきました。パフォーマンス低下の主な原因の 1 つがファイルスキャンにあることは最初から分かっていました。


近年のセキュリティ製品にはファイルスキャン以外にも多くの検出手段が搭載されていますが、ファイルスキャンはきわめて成熟した技術であり、非常に高い検出効率を誇っています。したがって今後もこの技術をなくすわけにはいきません。必要なのは、その使用方法を抜本的に見直し、システムパフォーマンスへの影響を最小限に抑えるということです。

ファイルスキャンのパフォーマンスは年々向上を続けています。これは主に、製品のメジャーバージョンアップごとにスキャン効率が約 10%~30% の割合で段階的に改善されていることによります。スキャンエンジンの改善は大変意味のあることなので、今後も継続していきます。

それとは別に、スキャンの回数自体を減らす技術についても研究してきました。こうして生まれたのがノートン インサイトです。これは当初、「SAPHIRE」というプロジェクト名で呼ばれていました。「Scan less by Avoiding Proven High Incident Recurring Entities(信頼できる頻出項目はスキャン対象から除外してスキャン回数を減らす)」の頭文字をとったものです。ノートン インサイトの動作を理解するには、まず現在のファイルスキャンのしくみを知っておく必要があります。



伝統的な「ブラックリスト」アプローチ

一般に、クライアント向けセキュリティソフトウェアは既知のシグネチャと照合しながらディスク上のファイルをスキャンしてマルウェアを検出します。シグネチャと一致したものが脅威と判定されます。この方式は、既知の不正なファイルをカタログに登録するという一種の「ブラックリスト」アプローチです。

この方式には 1 つの問題があります。それは、毎日数千もの新しい脅威の亜種が出現し、脅威の規模が拡大の一途をたどっていることに関係があります。つまり、ブラックリストが絶えず更新されているという点です。ブラックリストが更新されれば、最新のブラックリストに一致するファイルがないかどうか、全ファイルをチェックし直さなければなりません。一度スキャンしてクリーンと判定されたファイルも、最新版のブラックリストでは悪質なファイルと判定される可能性があるからです。

通常、ファイルのスキャンは作成時、アクセス時、変更時に行われます。ファイルもシグネチャも変更されていなければ、そのファイルに何度アクセスしても再度スキャンを行う必要はありません。最近のセキュリティ製品のほとんどは、ファイルがスキャン済みかどうかを判定するためのキャッシュを搭載しています。ファイルが変更されたりブラックリストが更新された場合はキャッシュのエントリを削除するようになっています。ブラックリストの更新に関しては、特にその頻度が高いとパフォーマンスのオーバーヘッドが大きく、システムの速度が低下します。


単純なアプローチではだめな理由

同じファイルを何度もスキャンするのを防ぐにはどうすればよいでしょうか。まず考えつくのは、一度スキャンしてクリーンと判定されたファイルや変更されていないファイルを次回のスキャン対象から除外するという単純な方法です。しかし、残念ながらこの方法はセキュリティを低下させてしまいます。一般に、最新の脅威はすぐには検出されず、新しいブラックリストが発行された後で検出されることが多いためです。たとえばあるトロイの木馬がいったんクリーンと判定された後でブラックリストに登録されたとします。このファイル自体が変更されることがなければ、以前のスキャンで検出されなかったという理由だけでこのファイルはコンピュータ上に存在し続けることになります。これではセキュリティソフトウェアの意味がないので、とうてい認めるわけにはいきません。


「ホワイトリスト」アプローチ

ブラックリスト方式にはもちろん長所もありますが、リストが更新されたならばスキャン済みのファイルを再度スキャンしなければならないというパフォーマンス上の問題があります。実は、この問題は正反対のアプローチで解決できます。正常であることが分かっているファイルをカタログに登録しておけば、再スキャンを避けることができるという考えです。正常であると確認されたファイルがその状態を変えるということは、通常は起こりえません。たとえば Office のインストールディレクトリにある winword.exe もそうです。このファイルはたくさんの人が使用しており、変更されることもありません。にもかかわらず、セキュリティ製品はこれをスキャン対象に含めているのです。

現在使用されているオペレーティングシステムや主流となっているアプリケーションは無数に存在するわけではなく、そのほとんどはよく知られたものばかりです。多くのシステムにはほとんど同じバージョンの同じバイナリファイルが存在しており、これらが変更されることはほとんど(あるいはまったく)ないのです。また、クライアント向けセキュリティソフトウェアは悪質なファイルやアプリケーションの異常動作をチェックするために常にシステムを監視していますが、このこともシステムのパフォーマンスを慢性的に低下させる結果となっています。だからといって、一般ユーザーがこうした悪質なファイルやアプリケーションに遭遇することはめったにないのです。


ノートン インサイトは、クライアントシステムに存在するごく一般的なファイルを識別するというアプローチを採用しており、これらのファイルをスキャンや監視の対象から除外します。

ノートン インサイトでは未知のファイルのみがスキャンおよび監視の対象となりますが、一般的なシステムでは未知のファイルは既知のファイルほど数が多くありません。このため、セキュリティソフトウェアがパフォーマンスに与える影響は、未知のファイルのみに限られます。つまり、よく知られた一般的なファイルは除外し、数少ない未知のファイルだけに絞って厳密な検査を行うのです。


増大するリスト

それでもまだ分からないことがあります。セキュリティ製品が正常なアプリケーションをすべて把握することなどできるのでしょうか。最初にお断りしておきますが、すべてを把握することなどとうてい無理です。しかしその大多数は特定可能なので、特定できなかったものを未知のファイルとしてスキャンすればよいことになります。

もちろん、正常なファイルを登録するホワイトリストは巨大なサイズになる可能性があります。ブラックリストに加え、巨大になったホワイトリストの定義ファイルもクライアントにダウンロードするというのは得策ではありません。そこで、ホワイトリストはシマンテックのサーバーに置き、インターネット経由で参照してもらうことにしています。

これを私たちは SAPHIRE バックエンドと呼んでいます。要するに、これは正常であることが分かっているすべてのファイルをリスト化した巨大なデータベースです。クライアントは、定期的にこのデータベースに対して問い合わせを行います。この処理はコンピュータが使われていないアイドル時間を利用して行われるので、システムのパフォーマンスには影響しません。また、ノートン インサイトの画面を最初に開いたときもバックエンドへの問い合わせが行われます。こうしてユーザーはいつでも自分のファイルを評価し、現在どのファイルが既知の正常なファイルで、どのファイルが未知のファイルかを判断できるのです。


コミュニティをウォッチして実際の状況を把握

ノートン Community Watch 機能はアプリケーションに関するセキュリティデータを提供し、そのデータをシマンテックに送信します。シマンテックでは、このデータを分析して新しい脅威やその発生源をつきとめることによって、より効率的なソリューションの提供に役立てています。ノートン製品のユーザーの方がノートン Community Watch 機能を有効にすると、ユーザーのシステムに存在する特定のプログラムファイルに関する情報がクライアントソフトウェアによって収集されます。もちろん、個人を特定できる情報がシマンテックに送信されることはありません。

ここで情報収集の対象となるファイルは、実行中のプロセス、実行中のプロセスでロードされたモジュール、登録されたドライバ、登録されたサービス、インターネットエクスプローラに登録されたブラウザヘルパオブジェクト、スタートアップグループまたはレジストリの run キーに登録されたスタートアップファイルです。基本的に、システムで実行中または実行可能なファイルはすべてこれらの中に含まれます。

これら対象となるファイルのそれぞれについて、SHA256 暗号化ハッシュがソフトウェアによって計算されます。SHA256 ハッシュはファイルを一意に識別し、ファイルにたとえわずかでも変更を加えるとファイルの SHA256 ハッシュが変化します。

クライアントからシマンテックには、ファイル名、ファイルのバージョン情報、SHA256 ハッシュが送信されます。シマンテックに送信されるのはファイルに関する静的情報のみです。ファイルのコピーは送信されません。ファイルを一意に識別する SHA256 ハッシュに基づいて、シマンテックはそのファイルがノートン Community Watch に参加している全システムにどの程度存在、分布しているかを統計的に分析します。


統計的分析とその利点

シマンテックでは、ノートン Community Watch 機能で送信された情報をもとに、ファイルの分布とファイルの信頼性に関する統計モデルを構築しています。シマンテックが独自に開発したアルゴリズムにより、信頼できるファイルを識別し、そのファイルに「コミュニティ信頼済み」の評価を与えることができます。

また、シマンテックは無数の SHA256 ハッシュを件数順にソートすることによって、最も一般的なファイルの静的属性も分析しています。バージョン情報とファイル名を分析することによって、ベンダーとアプリケーションの関連づけを行います。シマンテックはこれらアプリケーションのオリジナルメディアを入手し、外部からの汚染や感染のないクリーンな環境でインストールを行います。次に、インストールしたバイナリの SHA256 ハッシュの計算を含めた分析を行います。計算によって得られた SHA256 ハッシュ値と報告された SHA256 ハッシュ値が一致すれば、カタログに登録されたアプリケーションと報告されたファイルは同じものということになります。

アプリケーションに含まれるバイナリはすべて徹底的に分析されます。すべてのバイナリが安全でクリーンであると確認されれば、シマンテックはそのベンダを信頼できるものと判断し、これらのファイルに「ノートン信頼済み」の評価を与えます。


ノートン インサイトの分類

ノートン インサイトは、システムに存在する前述の種類のファイルをカタログに登録し、これらのファイルに SHA256 ハッシュを割り当てます。こうして、クライアントからノートン インサイトのバックエンドシステムに安全な接続が確立されます。クライアントからバックエンドにファイルの SHA256 ハッシュが送信され、バックエンドデータベースが参照されます。一致するものが見つかると、そのファイルに関連づけられた信頼属性がクライアントに送信されます。クライアントは、この信頼属性をファイルに関連づけます。ファイルが少しでも変更されるとそのファイルの信頼属性は失われることに注意してください。

ファイルに割り当てられた信頼属性がファイルのスキャンおよび分析のパフォーマンスにどのように影響するかは、スキャンのパフォーマンスプロファイルの設定によって異なります。ノートン製品では、パフォーマンスプロファイルを以下のいずれかに設定できます。

完全スキャン:ノートン インサイトの属性に関係なく、すべてのファイルがスキャン対象となります。つまり、ノートン インサイトによるスキャン回数の削減は行われません。

標準の信頼:シマンテックによって信頼済みのファイル(コミュニティ信頼済みまたはシマンテック信頼済み)はスキャン対象から除外されます。デフォルトではこの設定となります。

高い信頼:シマンテックによって信頼済みのファイル(コミュニティ信頼済みまたはシマンテック信頼済み)、または署名付きのファイル(Microsoft Catalog 署名付きまたは Authenticode 署名付き)はスキャン対象から除外されます。



パフォーマンス強化点

ノートン インサイトがどのようにシステムパフォーマンスへの影響を抑えているかを以下にまとめます。

  • 信頼済みファイル、頻繁にアクセスしているファイル、無制約で実行されているごく一般的なアプリケーションについてはセキュリティ評価を一切行わないので、全体的なシステムパフォーマンスと応答性が大幅に向上します。
  • 起動シーケンスで実行される信頼済みのドライバ、サービス、スタートアップアプリケーションをスキャン対象から除外することで、起動およびシャットダウン時間が短縮されます。
  • 信頼済みアプリケーションは起動時にスキャンを行わないので、アプリケーションの起動時間が短縮されます。
  • 信頼済みファイルはクイックスキャンやシステムの完全スキャンの対象から除外されるので、スキャン時間が短縮されます。

 

ノートン インサイトの他の利用法

ノートン インサイトで使用するアプリケーションのホワイトリストは、元々パフォーマンス機能として開発されたものです。しかしその後、他のセキュリティ技術にも非常に有用であることが分かりました。たとえばアクティブ検出ヒューリスティック機能は、信頼できるソフトウェアが不正なソフトウェアと同じような実行動作をすると、不正なソフトウェアと誤認してしまうことがあります。誤検出を防ぐにはヒューリスティック機能の感度を下げるのが一般的ですが、そうすると一部の不正なアプリケーションを検出できなくなります。

既知のアプリケーションをホワイトリストに登録してノートン インサイトを使用すると、既知の正常なアプリケーションはヒューリスティック検出の対象から除外されるため、ヒューリスティック検出感度のしきい値を大幅に引き上げることができ、悪質なアプリケーションの検出率が向上します。そこで、ヒューリスティック検出機能の起動時には毎回ノートン インサイトをチェックするようにしています。こうすることで、よく知られた正常なアプリケーションを不正なものと誤認するのを防いでいます。

また、この技術を利用するとアプリケーションが既知の正常なものかどうかを自動で簡単に判断できるので、よく目にする「許可しますか、禁止しますか」というポップアップも表示する必要がなくなります。この結果、シマンテックのセキュリティ製品はよりインテリジェントで、ユーザーにとってより快適なものになります。


想定問答集

Q:信頼済みファイルが変更されたら信頼属性を破棄してスキャン対象に戻さなければなりませんが、ファイルが変更されたことをどのようにして検出するのですか?
A:シマンテックのカーネルモードデバイスドライバ技術により、ファイルが変更されたら即座にファイル信頼属性が破棄されます。

Q:製品が実行されていない間(セーフモードで起動したり CD から起動した場合など)に信頼済みファイルが変更されていないとどうして分かるのですか?
A:起動時に NTFS ファイルシステムを分析し、掌握していない変更が認められた場合にはそのボリュームのすべてのファイルの信頼属性が破棄されます。

Q:コミュニティ信頼済みファイルを実際には分析していないのに、なぜ安全だと断言できるのですか?
A:シマンテックは独自に開発した統計的手法を用いてファイルをコミュニティ信頼済みと分類していますが、この手法は安全性のマージンをきわめて大きくとっているため、悪質なファイルを誤って信頼することはありません。

Q:それでも実際に誤って信頼した場合はどうなりますか?どのような情報をもとに、ファイルを再びスキャン対象に戻すのですか?
A:LiveUpdate の際に、破棄された SHA256 ハッシュのリストをクライアントが受信する「破棄メカニズム」が実装されています。この SHA256 ハッシュのリストに含まれているファイルを現在クライアントが信頼している場合、そのファイルの信頼属性はすべて破棄され、ファイルは再びスキャンの対象に戻されます。

Q:ノートン インサイトはどのようなファイルシステムでも、ネットワークドライブでも動作しますか?
A:いいえ。セキュリティ上の理由により、NTFS ボリュームのファイルしかサポートしていません。

Q:SHA256 を計算するよりファイルをスキャンした方がコストがかからないのではないですか?
A:そのとおりです。しかし SHA256 は 1 回計算するだけでよく、あとはそれをファイルに関連づけるだけです。いったん信頼されたファイルについては、スキャンを行うよりも信頼属性を参照した方がはるかに高速です。信頼されていないファイルは、ファイルにアクセスするたびにスキャンが実行されます。

Q:SHA256 と信頼属性をどのようにしてファイルに関連づけているのですか?つまり、ADS(Alternate Data Stream)と NTFS オブジェクト ID を使用してファイルに情報を関連づけている他社製セキュリティ製品と同じような問題が発生しますか?
A:シマンテック製品では、パフォーマンスと安全性の非常に高い製品固有のデータベースに情報を格納しています。通常のファイルシステムに影響を与えたり変更を加えたりすることはありません。

Q:パフォーマンスプロファイルの[標準の信頼]と[高い信頼]はどこが違うのですか。
A:[標準の信頼]では、セキュリティが確保されたシマンテックのバックエンドシステムで検証済みのファイルのみが信頼されます。[高い信頼]では、署名付きのファイルも信頼されます。この署名は、コンピュータのローカル証明書ストアと照合して検証されます。

2009年08月03日 16:39
にcomm_managerにより編集されたメッセージ