標準または一般的な分類と、残る不明物の扱い
昨日のBlogネタの続きというか、関連した話題になりますが標準的なファイルタイプを特定することで、標準でないファイルを把握していく伝統的な手法としては、ファイルタイプによる識別があります。この利点と、考え方・扱いについて再度考えてみたいと思います。
収集データにどの様な種類のファイルが含まれているかを簡単に確認する方法としては、拡張子を使いグループに分ける事ができます。
例えば、Doc,Xls,Ppt,PDFといったオフィス系文書ファイルの拡張子を一つのグループとしてまとめ、その件数やサイズを集計するといった処理になります。
例えば、データを人間が取り扱うグループに分類していくと、以下の様なグループに分類できます。この分類はあくまで例ですので、例えばより細かく暗号化ファイルのグループなどを作り分離する事もできます。また、少し引いてみて考えると、人間が作成したデータとシステムやアプリケーションに関連した二つのグループに分けて考えることも出来るかもしれません。人間の扱いによるグループ分けは今後の検討してみたい項目の一つです。
- Email:電子メール系の拡張子
- Office1：オフィス文書ファイル系の拡張子
- Office2：日本国内に特有なオフィス系文書ファイルの拡張子
- Archive：圧縮ファイル系の拡張子
- Graphics：画像系ファイルの拡張子
- Audio, Video：動画系ファイルの拡張子
- Program：プログラム関連ファイルの拡張子
- UnKnown：上記いずれのグループにも当てはまらない拡張子
上記ですが、3文字以内の拡張子だけで分類しますので、異なるアプリケーションにより重複して利用されているケースや、そもそも拡張子が無いMbox形式ファイル等もあり厳密な分類ではありません。
特にUnKnownと呼んでいるグループは、一般的でない拡張子をまとめたものですので、恐らく実務上は毎回かなりの件数になる事が推測されます。*1
例えば、TrueCryptのコンテナファイルに対して、その存在を隠そうとはせずに、律儀に.tcと拡張子を付与している場合、上記ではグループ分けしていない拡張子になるので、UnKnownに分類されてきます。
拡張子だけに依存したグループ分けは重箱の隅を突き出せば色々とあります。例えば、実行形式ファイルについてですが、圧縮ファイルの自己展開形式かもしれませんし、暗号化コンテナファイルかもしれません。（実行するとパスワード入力画面が表示されるタイプのツールなどもありますよね）
システムにインストールされているアプリケーションにより、拡張子が登録されている場合には、その情報を利用して紐づけ・グループ分けする事も可能になるかもしれません。または利用者による拡張子とアプリケーションのマッピングが行われていれば、その情報も役立つはずです。ただし、それらの情報は環境に依存し、標準的か？という部分ではバラツキが出る部分かと思います。このバラツキをいかに吸収または扱うかについては別途考えてみないといけないはずです。
より厳密に確認しグループ分けするには、ファイル拡張子だけでなく、ファイルの内容を読み取って拡張子と一致しているかどうかを判断する必要があります。フォレンジック系のツールでは一般的に搭載されている機能ですし、Index型の検索エンジンなどでも同じようにファイル種類を識別する機能が搭載されていたりします。
シグネチャ分析は、ファイルを読み込む必要があり、処理には一定の時間を必要とします。シグネチャ分析に相当する機能を実行する場合には、人間が機械からの結果を待たされる状況にならないように手順を工夫しておく必要があります。機械が人間を待たせるのは良くないとされています。
ファイルの識別精度ですが、これは利用するツール（またはエンジンと言うべきでしょか）に依存してきます。個人的に、色々なツールを使ってきた感覚と経験からすれば、いずれも完璧ではないという事です。テキストファイルをEncryptと識別したり、LZH形式ファイルをINIファイルと識別してしまうツール（エンジン）もあったりしますから、誤検出前提で使う必要があります。
また、どの様なパターンでファイルを識別しているかを容易に確認でき、変更する事ができるかについては、道具を選別する上で重要なポイントかもしれません。
ファイル識別が誤検出される場合、検出結果を変更する、または検出パターンを変更して検出処理をやり直す、の二つのアプローチがありえますが、前者は不良をチェックするのが容易ではなく、後者のパターンを修正する方が良いと考えています。
ただし、いずれの方法を取るにしても、誤検出という不良をいかに見える化し、不良と検出できるようにするかは工夫の余地があります。
誤検出するのは仕方がないとして、誤検出していることを簡単に識別できない事が問題の本質だったりするのかもしれません。フォレンジック系のツールでは、不良品の検出という概念が少ないのかもしれません。製造元会社の文化も大きいのでしょうか。
脱線しましたが、シグネチャ分析を行えば、UnKnownに分類された正体不明ファイルの中に混じっている既知ファイルを更に分類していく事ができます。*2
ありがちなのが、ユーザーが拡張子を誤って付与しているケースです。例えばＸＬＳのように全角の拡張子を付けている、ZI_ または _IP のようにZIPの拡張子を変更しているといったケースは、シグネチャ分析に一般的なファイルのエイリアスとして更に除外して分類できるはずです。
- 標準的なファイル拡張子で分類
- 分類できない拡張子をUnKnownとして分離しシグネチャ分析結果を確認
- UnKnownから既知ファイルのシグネチャを更に分離する
- 残ったものが標準的でないファイル
さて、標準的でないファイル拡張子を分離してみましたが、この正体不明なファイルたちについてはどう処理すべきでしょうか？何に注目して見るべきでしょうか？
例えば、マルウェアが拡張子を DLL(dll) ではなく数字を混ぜた D1l または d1l と表示していた場合はどうなるでしょうか？、このファイルの中身が実行形式であれば、上記3の段階で既知ファイルのエイリアスとして分離されて4まで残らないはずです。
TrueCryptの暗号化コンテナファイルで拡張子が無い場合はどうでしょうか？、4まで残ってくるはずです。しかし、4まで残るファイルが意外に？多いので、この段階からの絞り込みにはもう少し工夫や手順が必要になるはずです。
不明なファイル拡張子が存在する⇒どのアプリケーションにより作成されたファイルか、または用途を特定できない⇒なぜアプリケーションとの紐づけができないのか？
と考えてみると、先ほど少し出ていた、アプリケーションがシステムに登録している拡張子情報を活用する手順についても取り入れることで、不明なファイル拡張子を分類できる可能性が出てきます。
一般的にはファイルのヘッダとフッタを使ってファイルのシグネチャを生成する事が多いと思われますが、ここは工夫できないものでしょうか？、処理時間とのバランスを取る必要がありますが、ファイル内のキーワードなども分析対象に含める、またはそれ以外の属性値などもファイルの正体分析に含める方法が作れないものでしょうか？
新たな紐づけ方法が発見され、シグネチャが特定できるのであれば、その紐づけを検出の手順に組み込んでいけますので、次の案件ではより流れがよくなるのではないでしょうか。
とはいえ、それでも不明ファイルが残ってきますので、そのファイルがどの様な生まれでそこに存在するのかを特定する方法を考える必要があります。
また、標準的と分類した中に不審なファイルが含まれている可能性についても考慮しなければいけませんが、どの様な生まれのファイルか？という手法を標準ファイルにあてはめていく事はできるかもしれません。
