復元手順書に誰も書かないステップ

私たちが読んだ復旧計画は、どれもデータがどれだけ早く戻るかで測られます。 復旧時間目標、復旧時点目標、ダウンタイムの時間数、1時間あたりの失われる 売上。これらは役員向けスライドに載る数値であり、復旧が担うべきことの大半にとっては正しい 数値です。

そして、それがこの地域のほぼすべての手順書から1つのステップが抜け落ちている理由でもあります。

2つの日付

まずはタイムラインから始めましょう。タイムラインこそが、この仕組みのすべてだからです。

ある日に侵害されます。後日のある時点でそれに気づきます。これが滞留時間です。つまり、侵入者が入り込んでから誰かが 気づくまでの間隔です。分単位ではなく、日や週で測ります。正確な数値は インシデントごとに異なりますが、その形のほうがはるかに重要です。

では、復旧チームがどのバックアップを使うのかを考えてみてください。彼らは、クリーンだと考えられる最も 新しい復元ポイントを使います。実務上は、インシデントが検知される前に取得された最も 新しい復元ポイントを意味します。なぜなら、検知だけが、全員が合意できるタイムスタンプを持つ出来事だからです。

その2つは別の日付です。その間のギャップで作成、受信、または変更されたものはすべて バックアップの中に含まれており、インシデントの引き金となった悪意ある文書は、ほぼ確実に誰かが何かに気づく前に作成されています。 バックアップは忠実なコピーです。ペイロードについても忠実です。

ステップを消してしまう指標

ここから先はあまり注目されない部分ですが、これは技術の問題では まったくありません。

復旧は経過時間で評価されます。資産全体が停止している1時間ごとにカウントされ、 多くの場合は売上の数字を見ている人たちによって数えられます。復元した 文書をすべて検査または再処理すると、復旧責任者が評価されるまさにその数値に何時間も上乗せされます。そしてそれが最もまずいタイミング、つまり インシデント終息を宣言したい圧力が最も高い瞬間に発生します。

誰も手順書に「ファイルの衛生管理を省略した」とは書きません。そういう 起こり方ではないからです。そのステップは最初から手順書に入っておらず、どの指標もそれを求めず、 復旧は予定どおり完了しました。インセンティブが静かに仕事をしたのです。

そのため、パターンは繰り返されます。クリーンなイメージから再構築されたサーバー、ローテーションされた認証情報、 再イメージ化されたエンドポイント、今回は適切に分離されたネットワーク。すると、ファイル共有、 メールボックス、文書リポジトリが、まったく以前のまま戻ってきます。 手つかずのままです。誰も再構築しない唯一の層は、その中身を運んでいた 層なのです。

再スキャンが適切でない理由

明らかな答えは、復元する前にバックアップをスキャンすることですが、なぜそれが見た目ほど強力ではないのかを正確に見ておく価値があります。

あなたの検知スタックは、このファイルをすでに一度、到着したその日に識別できませんでした。復元時には、同じ種類のエンジンを同じファイルに向け、既知の悪性項目という同じ目録を探しています。キャンペーンが騒がしく広く報告されていたなら、シグネチャは追いついていたかもしれません。そうでなかった場合、あるいはその文書があなた専用に作られていた場合は、追いついていません。

サンドボックスにも同様の限界があります。設計された範囲でしか機能しないのです。ユーザー操作、特定のロケール、まだ到来していない日付を待つペイロードは、起爆時には申し分なく振る舞い、必要な時間だけ正確に申し分なく振る舞います。

もっと静かな失敗もあります。再スキャンは判定を生みますが、判定は証拠ではありません。「何も見つからなかった」は、そのファイルについてではなく、あなたの検知カバレッジについての記述です。

リストア後の衛生ステップはどのようなものか

実用的なやり方では、バックアップから出てきたファイルを、見知らぬ相手から届いたファイルと同じように扱います。復旧の最中には、それがまさにその由来だからです。

具体的には、復元とサービス復帰の間に1つのステップを挿入します。

1. 検査ではなく再構築する。 各文書を構成要素に分解し、公開仕様に照らしてそれぞれを検証したうえで、その中間表現からまったく新しいファイルを作成します。つまり、元のバイト列ではなくレシピです。この違いは、見た目以上に重要です。エンジンが良好と判断した部分をそのままコピーするのも、何が安全に見えるかという判断にすぎず、見た目を変えた検知に過ぎませんし、元のファイルは依然としてそこにあります。再構築では元のファイルを一切通さないため、認識されないことで生き残るものはありません。これが決定論的な Content Disarm and Reconstruction の仕組みです。Glasswall は、827万件のテスト済みファイルに対して悪性ファイルの100%を無力化したと報告しており、その政府研究センターのケーススタディでは、この順序で復旧を行った例が説明されています。
2. 記録はファイルごとに残す。 各文書について、何を、どの policy の下で、いつ削除したのか。これはインシデント報告に必要な証跡であり、評価者が求める証跡でもあります。後から再構成することはできません。
3. 優先順位はアルファベット順ではなく、爆発半径で決める。 共有ドライブ、メールボックス、そして自動パイプラインが消費するものは最優先です。月次のマクロ駆動プロセスに供給される財務共有領域は、誰も開かないアーカイブよりも上位の問題です。
4. 環境はまだ分断されたままだと想定する。 復旧の途中では、ファイルを送るためのネットワークがないことが多く、だからこそデスクトップ常駐の処理が、平常時にはない重要性を持ちます。Glasswall Meteor はエンジンをローカルで実行し、オンライン、オフライン、またはエアギャップ環境でも動作します。 8.27

これらはどれも華やかではなく、新しいエンジニアリングでもありません。必要なのは1つのステップと、そのために時間を使うという決断です。

証拠の側面

このステップを追加する2つ目の理由は、この地域ではその義務がすでに文書化されており、制御上の義務であると同時に証拠上の義務でもあるからです。

シンガポールの Cybersecurity Code of Practice for Critical Information Infrastructure は、条項 6.1.4 でこれを明確にしています。記録した事象の後、少なくとも12か月間保持すること、不正な変更や削除から保護すること、そして「サイバーセキュリティインシデントの調査を容易にするため、log retention policy によって管理されること」。保持の明示された目的はアーカイブではなく、調査です。

MAS Technology Risk Management Guidelines は、金融機関に対して同様の期待を示しています。メール、アップロードポータル、または第三者交換経由で到着した信頼できないファイルは、検知判定だけで受け入れるのではなく、境界で処理されます。

インシデント後にこれらを合わせて読むと、評価者が持ってくる問いは「何をブロックしたか」ではありません。「この文書に何が起きたのかを見せてください」です。例外だけを記録する制御ではそれに答えられません。通過を許可したファイルについては、ファイルごとの記録がまったく生成されないからです。再構築ステップは、触れたすべてのファイルについて記録を生成します。完全に問題なかったものも含めてです。だからこそ、その記録はアラート履歴ではなく証拠として使えるのです。

問う価値のある質問

復旧計画は訓練されます。リストア後の衛生ステップは、2回目のインシデントの後に追加されます。それは、学ぶには高くつく場所です。

復旧の承認にあなたの署名が必要なら、チームへの問いは「データがどれだけ早く戻ったか」ではありません。「何を戻したのか、そしてどうやってそれを知るのか」です。

シンガポールにおける義務全体の詳細については、Cybersecurity (Amendment) Act 2024 および 2026年7月に発表された CCoP 更新を含め、Singapore compliance page をご覧ください。