証拠として説明できる形で取り出すライトブロッカーと保全用機材の選び方

社内で不審な挙動が見つかったとき、まず手が伸びるのは対象のディスクです。取り外して手元のPCへUSB変換アダプタで挿し、中身を見に行く、という動き方をしてしまうと、その瞬間に調査対象そのものが書き換わる可能性があります。後日「このデータは改変されていない」と説明する必要が出たとき、説明できる材料が残りません。

この記事は、端末やディスクの内容を後から証拠として説明できる形で取り出すために、どんな機材を選び、どんな手順で使うかを整理します。対象は情報システム担当と社内のインシデント対応担当です。製品のランキングではなく、判断の材料を示すことに徹します。記述はNISTのCFTTとSP 800-86、RFC 3227、米国DHS科学技術局が公開する検証結果、個人情報保護委員会とe-Gov法令検索、JPCERT/CCの公開資料で確認できた範囲に限り、確認できなかった数値や仕様は書きません。

先に、保全手段ごとの性格を一覧にします。

接続しただけで書き込みが起きる仕組み#

ディスクを取り外して手元のPCへ挿すと、OSはそれをストレージとして認識し、パーティションテーブルとファイルシステムを読み、条件が合えば自動的にマウントします。ここまでは読み出しだけで済む場合もありますが、マウント後の処理で書き込みが発生します。

書き込みの発生源はいくつもあります。ジャーナリングファイルシステムは、前回の停止が正常でなければマウント時にジャーナルの回復処理を行い、その結果をディスクへ書きます。ファイルを開けばアクセス時刻が更新される設定のこともあります。デスクトップ環境が接続を検知してサムネイルの生成やインデックス作成を始めれば、それも書き込みです。ボリューム側に管理用のフォルダやメタデータが作られることもあります。

厄介なのは、この一覧が環境ごとに違ううえ、公式に網羅された一覧が存在しない点です。OSの版、デスクトップ環境、常駐しているソフト、ファイルシステムの種類によって、何がどこへ書かれるかが変わります。NIST SP 800-86も、誰もそのコンピュータを使っていない状態でも、稼働しているサービスやプロセスがハードディスクへ書き込んでいることがあるという注記を置いています。

ここから導かれる方針は単純です。何が書かれるかを個別に把握して避けるのではなく、そもそも書き込みが物理的に届かない経路を作る、という組み立てにします。それが書き込み防止装置の役割です。

フォレンジック全般の考え方は別記事で整理しています。機材の話に入る前に、調査の流れを押さえておくと選定の判断が早くなります。

あわせて読みたい

ログからの侵害調査（フォレンジック）の基本。証拠保全とタイムライン再構成

NIST CFTTが定める書き込み防止装置の要件#

「書き込みを防ぐ」と書かれた製品が本当に防いでいるかは、外から見ただけでは分かりません。この問題に対して、NISTはComputer Forensics Tool Testing(CFTT)というプロジェクトで、フォレンジックツールの機能要件と試験手順を公開しています。CFTTは米国司法省の研究開発部門であるNational Institute of Justice(NIJ)とNISTの共同プロジェクトとして始まり、FBIや国防総省のサイバー犯罪センターなども支援していると仕様書に記載されています。

ハードウェア側の要件は「Hardware Write Blocker Device (HWB) Specification, Version 2.0」(2004年5月19日)にまとまっています。この仕様は、インタフェースを流れるコマンドの操作を4つの分類に分けます。データを変更する、変更を引き起こしうる、変更の前提になる、インタフェース仕様で未定義である、ホストへの見せ方を変える、設定可能なパラメータを変える、のいずれかに当たる操作をModifying(変更系)とし、残りをRead(読み出し)、Information(情報取得)、Other Non-Modifying(その他の非変更系)に振り分けます。

そのうえで必須要件を4つ置いています。

HWB Specification Version 2.0の必須要件は次の4つです。HWB-RM-01は、ホストからどの分類の操作を受け取った場合でも、また動作中のいかなる時点でも、保護対象の記憶装置へ変更系の操作を送出してはならないと定めます。HWB-RM-02は、読み出し系の操作を受け取ったときに要求されたデータを返すことを求めます。HWB-RM-03は、情報取得系の操作に応答するとき、記憶装置へのアクセスに影響する情報(access-significant information)を書き換えないことを求めます。HWB-RM-04は、記憶装置が報告したエラー状態をホストへ伝えることを求めます。

この4つは、そのまま選定時の考え方になります。単に書き込みを止めるだけでなく、容量やセクタ数のような情報を正しく返すことが要件に入っている点が実務では効きます。仮に装置がセクタ数を少なく申告すれば、取得ツールは末尾の領域を読みに行かず、欠けたイメージができあがります。それでもハッシュは一致してしまうため、欠けに気づけません。

注意したい点として、この仕様が対象とするインタフェースはATA、SCSI、USB、FireWireに限ると明記されています。2004年の文書であるためNVMeは範囲に入っていません。NVMe対応の装置を検討する場合は、仕様そのものではなく、後述する個別の検証結果報告を確認することになります。

ハードウェア型とソフトウェア型の違い#

ソフトウェア側にもCFTTの仕様があります。「Software Write Block Tool Specification & Test Plan, Version 3.0」(2003年9月1日)がそれで、ツールがBIOSのinterrupt 0x13の入口を自分の処理に差し替え、アプリケーションが発行するディスクI/Oを横取りして、ブロックすべきコマンドかどうかを判定する動作を前提にしています。必須要件には、保護対象ドライブへの書き込み系と構成変更系の操作を遮断すること、読み出し系と情報取得系は遮断しないこと、ツールが有効であることを利用者に示すこと、各ドライブの保護状態を報告することなどが並びます。

前提がBIOSのinterrupt 0x13に置かれている点は見落とせません。現代のOS上で動くツールとは仕組みが違うため、この仕様への適合をもって「いまのWindows上でも安全」とは言えません。NIST SP 800-86も、当時の状況としてソフトウェア型はMS-DOSとWindows向けにしか存在しないこと、MS-DOS向けはinterrupt 13と拡張interrupt 13の書き込みを捕捉する仕組みであること、Windows向けはデバイスへ送られる割り込みをフィルタで選別する仕組みであることを説明しています。

現行環境でよく使われる設定にも、明示された限界があります。

Linuxのblockdev --setroはブロックデバイスを読み取り専用にするコマンドですが、マニュアルには、その時点で有効になっているアクセスは変更の影響を受けないこと、たとえばすでに読み書きモードでマウントされているファイルシステムには影響しないこと、変更は再マウント後に効くことが書かれています。つまり、挿してマウントされた後に実行しても手遅れです。

blockdev(8)のマニュアルは、--setroの説明として「現在有効なデバイスへのアクセスは、この変更の影響を受けないことがある。たとえば、すでに読み書きモードでマウントされているファイルシステムは影響を受けない。変更は再マウント後に適用される」と記載しています。

Windowsでは、リムーバブルディスクへの書き込みアクセスを拒否するポリシーが用意されています。Microsoft Learnのポリシー一覧にはRemovableDiskDenyWriteAccessとして記載があり、有効にするとそのリムーバブルストレージクラスへの書き込みアクセスが拒否されると説明されています。ただし対象はリムーバブルストレージクラスであり、内蔵ディスクとして認識される接続形態では期待どおりに働くとは限りません。

まとめると、OS側の設定は、接続形態ごとに事前検証したうえで使う補助策として位置づけるのが現実的です。証拠として使う可能性のある原本に対して、検証していないOS設定だけを頼りに接続することは避けます。SP 800-86は、ソフトウェア型の書き込み防止は媒体を接続する前に読み込ませておくこと、書き込み防止の仕組みは新しい種類のデバイスに対応できるか定期的に試験することも示しています。SP 800-86も、Mac OS XやLinuxのように二次デバイスをマウントしない起動構成が組めるOSではソフトウェア型が不要な場合があるとしつつ、ハードウェアの書き込み防止装置を接続すれば完全性が保たれると述べています。

検証結果が公開されているかを確認する#

CFTTの要件が定まっていても、個々の製品がそれを満たしているかは別の話です。ここで使えるのが、米国国土安全保障省の科学技術局(DHS S&T)が公開している検証結果の報告書です。CFTTの試験手順に沿って実施した結果が、製品名とファームウェアの版とともにPDFで公開されています。

たとえば2023年1月付の報告書は、Tableau Forensic Universal Bridge T356789iu-R2(Digital Intelligence UltraBay 4)のファームウェア22.3.0を対象に、Federated Testing Suite for Hardware Write Blockingで試験した結果を掲載しています。SATAやSAS/SATAといったデータコネクタごとにテストケースが分かれており、結果の要約には試験した各シナリオで期待どおりに動作したと記載されています。2022年9月にはWiebeTechのNVMe書き込み防止装置についての報告書も公開されています。

報告書を読むときに見るのは3か所です。1つ目は対象製品のファームウェアの版で、手元の機体と一致しているかを確認します。2つ目は試験されたインタフェースで、SATAの結果だけが載っている製品をNVMeの保全に使う根拠にはできません。3つ目は結果の要約の記述で、異常が観測された場合はその内容と条件がここに書かれます。

DHS科学技術局はCFTTの試験結果報告書を公開しており、ハードウェア書き込み防止装置、ディスクイメージング、モバイル端末からの取得など分野ごとに報告書が並んでいます。報告書には対象製品名、ファームウェアの版、試験環境、テストケースごとの結果が記載されます。

検証結果が公開されていない製品が直ちに使えないわけではありませんが、後から第三者へ説明する場面では、公開された試験結果があるかどうかで話の進み方が変わります。訴訟や懲戒の可能性がある案件に使う機材は、この点を選定の条件に入れておくと後で困りません。

選定でみる軸#

候補を比べる前に、自組織の条件を先に並べます。次の表の左列を埋めてから、製品の仕様書と突き合わせる進め方が早道です。

ハッシュ計算とログ出力は、価格帯の差が出やすいところです。専用機には取得と同時にハッシュを計算し、作業記録を出力する機能を持つものがあります。汎用の変換アダプタに書き込み防止機能を足した構成では、記録は取得ソフト側と手書きの台帳で担保することになります。どちらでも成立しますが、記録の残し方を先に決めておかないと、後から埋められません。

もう一つ見落としやすいのが、対象がディスク単体ではない場合です。ノートPCの多くはM.2のNVMe SSDを使い、機種によってははんだ付けや暗号化の都合で取り外して読む前提が崩れます。自己暗号化ドライブや、OSの暗号化機能が有効な端末では、ディスクを抜いて接続しても暗号文しか読めません。この場合は稼働中の端末から取得する方針に切り替える判断が必要になり、機材の選定より先に手順の設計が効いてきます。

複製の実務とハッシュによる同一性の確認#

保全の中心は、対象ディスクをビット単位で複製し、その複製を調べる形に持ち込むことです。SP 800-86はこれをbit stream imagingと呼び、空き領域やスラック領域を含めて元の媒体のビット単位の写しを作る方式だと説明しています。論理バックアップはファイルやパーティションの複製にとどまり、未割り当て領域を無視するものがあるため、削除の痕跡を追う調査では足りません。

同一性の確認はハッシュで行います。SP 800-86は、イメージングを実施する際の手順として、複製の前に元媒体のメッセージダイジェストを計算して記録し、複製の後に複製側のメッセージダイジェストを計算して元の値と比較し、さらに元媒体のメッセージダイジェストをもう一度計算して、複製の処理が元媒体を変更していないことを確かめ、すべての結果を記録することを示しています。元媒体側で2回計算するのが、この手順の要点です。

NIST SP 800-86(2006年8月)は、複製前に元媒体のメッセージダイジェストを計算して記録し、複製後に複製側のダイジェストと比較し、その後で元媒体のダイジェストを再計算して複製処理が元媒体を変更していないことを検証し、すべての結果を文書化する手順を示しています。同文書はMD5とSHA-1を挙げ、連邦機関はFIPS承認アルゴリズムであるSHA-1を使うべきだとしていますが、これは2006年時点の記述です。

アルゴリズムの選択は、この記述をそのまま持ち込まないほうがよいところです。SP 800-86は2006年の文書で、当時の状況を反映してSHA-1を挙げています。現在のSecure Hash StandardであるFIPS 180-4はSHA-1に加えてSHA-224、SHA-256、SHA-384、SHA-512などを規定しており、新規に記録を残すならSHA-256を使う判断が取りやすくなります。取得ツールによってはMD5とSHA-256を同時に計算できるため、両方を記録しておけば、後から別の事業者が検証するときにも突き合わせやすくなります。

保存形式にも選択肢があります。rawイメージ(ddで作るようなセクタの並びそのもの)は扱いが単純で、コンテナ固有の展開処理が要らないため多くのフォレンジックツールで扱いやすい形式です。一方でExpert Witness Compression Format(EWFと呼ばれ、拡張子はE01などになります)は、圧縮と分割に加えて、取得したケースの情報やハッシュを同じファイル内に持てます。この形式の詳細はlibewfプロジェクトが公開しているドキュメントにまとまっており、オープンソースの取得ツールや解析ツールが対応しています。

ハッシュを突き合わせる対象は、保存形式によって変わります。rawイメージであれば、元媒体とイメージファイルの同じ範囲のバイト列を直接比較できます。EWFはヘッダや圧縮やメタデータを含む容器なので、E01ファイル自体をハッシュにかけても元媒体の値とは一致しません。容器に格納された取得対象データについて取得ツールが算出したハッシュを、ewfverifyのような検証コマンドで確かめます。読み出しエラーが出た区画がある場合は、その扱い(ゼロ埋めなど)とエラーログも一致判定の記録と一緒に残します。

取得ツールの例としては、GUIで取得とハッシュ計算を行うGuymager、解析側で広く使われるThe Sleuth Kitなどがあります。どれを使う場合でも、次の3点を作業記録に残します。取得を行った日時と担当、対象の識別情報(型番とシリアル番号)、取得前後のハッシュ値です。

揮発性の高い情報の順序と電源を切る判断#

ディスクの保全だけを考えていると、電源を切った時点で失われる情報を取りこぼします。RFC 3227「Guidelines for Evidence Collection and Archiving」(2002年2月、BCP 55)は、証拠を集める順序を揮発性の高いものから並べる考え方を示しています。

RFC 3227の2.1節は、揮発性の順序として、レジスタとキャッシュ、ルーティングテーブルとARPキャッシュとプロセステーブルとカーネル統計とメモリ、一時ファイルシステム、ディスク、対象システムに関係する遠隔のログと監視データ、物理的な構成とネットワークトポロジ、アーカイブ媒体、という並びを挙げています。

同じ文書の2.2節は、避けるべき行為も挙げています。証拠が失われるおそれがあるためシステムをむやみに停止しないこと、侵害された可能性のあるシステム上のプログラムを信頼せず保護された媒体から収集ツールを実行すること、ファイルのアクセス時刻を変えるコマンドを避けること、ネットワークからの切り離しが攻撃者の仕掛けた消去動作を引き起こす可能性があることなどです。3節では、収集の方法が透明で再現可能であり、独立した専門家が用いた手法を検証できる必要があるとしています。

実務では、次のような判断の順になります。まず、メモリの内容や現在の通信状態のように電源を切ると消える情報が調査に必要かを考えます。必要であれば、稼働中の状態でメモリイメージとネットワーク接続状況を取得します。次に、その端末がネットワーク上で被害を広げている可能性を評価し、通信の遮断が先か情報の取得が先かを決めます。最後に電源を落とし、ディスクを取り外して保全します。

電源を切る方法にも判断が要ります。OSの正規の手順で終了すると、終了処理の中でログの書き出しやキャッシュの破棄が起き、状態が変わります。一方で電源を強制的に落とすと、書き込み途中のデータが壊れる可能性があります。どちらを選んだかと、その理由を記録に残しておくことが、後からの説明では効いてきます。

初動全体の組み立ては別記事で扱っています。機材を揃える前に、誰が何を判断するかを決めておくと、現場で迷いません。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

保全に付随する備品と記録の残し方#

書き込み防止装置だけ買っても、保全の運用は回りません。周辺の備品は地味ですが、後から「この原本は途中で誰にも触られていない」と説明するための材料になります。

タンパーエビデントバッグは、一度封をすると開封の痕跡が残る袋です。封ごとに固有の番号が印字されているものを選ぶと、その番号を台帳へ記録することで、封をした時点と開封した時点を結びつけられます。開封の痕跡が残らない普通の袋では、この説明ができません。

静電気防止袋は、取り外した基板やSSDを扱うときに使います。導電性のシールドを持つ袋と、帯電を防ぐだけの袋では性質が違うため、用途に合わせて選びます。タンパーエビデントバッグの中に静電気防止袋ごと入れる、という二重の運用が扱いやすい形です。

証拠ラベルは、対象を取り違えないために使います。案件番号、対象の識別情報、取得日時、担当者を書ける大きさのものを選びます。剥がれにくく、書いた文字がにじまないものが向きます。

保存先のディスクは、取得したイメージを書き込む先です。rawやディスク間の複製では対象以上の容量が要り、圧縮するEWFの場合も圧縮率は保証されないため対象の容量以上の空きを見込みます。複数台を並行して保全するなら合計で見積もります。複製の保管は、原本の保管とは別の場所に置く形が扱いやすくなります。

記録用の台帳は、紙でも表計算でもかまいませんが、誰がいつ何をしたかを時系列で追える形にします。RFC 3227が求める「独立した専門家が手法を検証できる」状態は、この記録の積み重ねで作られます。保管場所の移動、担当者の交代、封の開閉は、そのつど記録します。

記録の残し方はログ管理の設計と地続きです。どこに何を残すかを決めておくと、調査のたびに作り直す手間がなくなります。

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

調査してよい範囲と社内の手続き#

技術的に可能かどうかと、行ってよいかどうかは別の問題です。保全は記録された内容をそのまま取り出す行為であり、対象には業務上のデータだけでなく個人に関する情報が含まれます。手続きを整えないまま進めると、調査そのものが問題になります。

前提として、対象にできるのは自組織が管理する機器か、所有者やアクセス管理者から調査とデータ取得について権限と承諾を得た機器に限られます。リース機器、委託先が管理する機器、私物の端末、顧客から保全を委託された媒体は、機器の所有権と管理権限と外部サービスへのアクセス権限をそれぞれ別に確認したうえで扱います。権限も承諾もないまま第三者の機器や他人が管理する通信に手を出すことは認められません。不正アクセス行為の禁止等に関する法律(平成十一年法律第百二十八号、1999年8月13日公布)は、他人の識別符号を用いるなどしてアクセス制御機能による制限を免れる行為を禁じています。自社の管理下にある機器を調べる場合であっても、そこに保存された他人のアカウント情報を使って外部のサービスへログインする行為は、この法律との関係が生じます。調査で得た認証情報をそのまま使わない、という線引きを最初に共有しておきます。

従業者の端末を調べる場合の参考になるのが、個人情報保護委員会が示す留意点です。このQ&Aが対象としているのは、個人データを取り扱う従業者の監督として行う継続的なモニタリングであり、事後の端末調査に直接あてはまる要件として書かれたものではありません。考え方として参照できる範囲で読み、個別の調査では就業規則と情報セキュリティ規程、調査の目的と必要性、対象の範囲、本人への通知の可否を法務と人事に確認して進めます。

個人情報保護委員会のQ&Aは、従業者を対象とするビデオやオンラインによるモニタリングの実施にあたり、モニタリングの目的をあらかじめ特定して社内規程等に定め従業者に明示すること、実施に関する責任者とその権限を定めること、実施に関するルールを策定しあらかじめ定めて運用者に徹底すること、モニタリングが適正に行われているか確認することを留意点として示しています。あわせて、社内規程に定める重要事項を定めるときは、あらかじめ労働組合等へ通知し必要に応じて協議することが望ましく、定めた事項を従業者に周知することが望ましいとしています。

なお、同Q&Aが労働組合等への通知や協議、従業者への周知について述べているのは「望ましい」という位置づけで、一律の法的義務として示されたものではありません。それでも、インシデント発生後にはじめて規程を作るのでは間に合いません。平時のうちに、調査を行う条件、実施する責任者、対象となる機器の範囲、取得したデータの保管期間と削除の手順を定め、従業者へ周知しておきます。

内部不正の疑いがある案件は、調査の進め方そのものが争点になりやすい領域です。手続きの組み立てについては別記事もあわせて確認してください。

あわせて読みたい

内部不正による情報持ち出しを機会と動機の両面から抑える統制の作り方

自前でやる範囲と外部に任せる範囲#

すべてを自前でやる必要はありません。線引きの目安は、その調査結果を誰に対して説明するかで決まります。

社内で原因を特定して再発防止につなげるところまでが目的なら、自前の保全と調査で足りることが多くなります。感染したマルウェアの特定、侵入経路の推定、影響範囲の確認といった用途です。この場合でも保全の手順を守っておくと、後から方針が変わったときに選択肢が残ります。

一方で、懲戒処分の根拠にする、取引先へ報告する、警察へ相談する、訴訟で使う可能性がある、といった場面では、早い段階で外部の専門事業者や法務へ相談する判断が向きます。第三者による報告書という形になることに加え、自前の作業で原本を触ってしまった後では取り返しがつかないためです。

実際の運用では、次のような役割分担が組みやすくなります。自組織は初動の記録と、原本を触らずに保全することまでを担当します。詳細な解析と報告書の作成は事業者へ渡します。この形にしておけば、事業者へ渡す前の状態が記録として残り、引き継ぎもスムーズになります。

外部への相談先としては、JPCERT/CCがインシデントの報告受付とCSIRTマテリアルの公開を行っています。組織内にCSIRTを立ち上げる段階の資料もまとまっているため、体制づくりの参考になります。警察への相談は、警察庁のサイバー警察局のページから各都道府県警察の窓口をたどれます。

漏えいが確認された場合の報告義務や連絡の流れは別記事で整理しています。

あわせて読みたい

情報漏えい発生時の対応と公表。委員会への報告義務と本人通知をどう判断するか

機材選びの候補#

以下は日本国内で入手しやすいカテゴリの例です。掲載する情報は執筆時点のもので、性能や適合性を保証するものではありません。対応インタフェース、書き込み防止の実装、電源仕様、検証結果の有無は、購入前に必ずメーカーの公式仕様で確認してください。

まとめ#

保全の良し悪しは、機材の価格ではなく手順で決まります。書き込みが届かない経路を先に作り、取得の前後でハッシュを突き合わせ、誰がいつ何をしたかを記録に残す。この3つが揃っていれば、後から説明を求められたときに材料が手元にあります。

機材を揃える前に、どのログとどの通信を残しているかを見直しておくと、保全に頼らずに済む調査が増えます。取得点の設計とあわせて検討してください。

あわせて読みたい

通信を取りこぼさずに記録するネットワークTAPとミラーポート機器の選び方