捕まえたあと、まず何をするか

一言でいうと

対応は、順序の勝負です。隔離は証拠を消し、証拠の収集は被害を広げます。そのため、何を今やり、何をあとでやるかをあらかじめ決めておき、インシデントのときは、その表に従います。

なぜ必要なのか

アラートが鳴ったあとの30分間に起きることは、たいてい次のとおりです。誰かがPodを削除します。誰かがノードを再起動します。誰かがcronファイルを消します。1時間後に「どうやって侵入されたのか」と尋ねても、誰も分かりません。侵入経路を持っていたものを、すべて消してしまったからです。

逆の方向も失敗です。証拠を完璧に集めようとして手を付けずにいる間に、その資格情報で別のネームスペースが侵害されます。

そのため、対応の手順は、「何が正しいか」ではなく、「何を先にするか」の問題です。NIST SP 800-61が長く引用される理由も、これです。検知・分析のあとに、隔離・根絶・復旧が来て、その間の判断基準を、インシデントの前に決めておくよう求めています。

どう動くのか

実務で使う順序は、4段階に絞れます。

1. 범위 정하기   무엇이 있는지 세고, 각 자료가 언제부터 언제까지인지 적는다
2. 증거 보존     원본은 건드리지 않고 사본 + 해시. 휘발성이 큰 것부터
3. 타임라인      출처가 다른 기록을 하나의 시간축(UTC)에 올린다
4. 격리·근절     표에 따라 조치. 각 조치에 근거 한 줄

このコードブロックの韓国語は、4つの段階を、範囲の設定(何があるかを数え、各データがいつからいつまでかを書く)、証拠の保全(元には触れず、コピーとハッシュを残す。揮発性が高いものから)、タイムライン(出所の異なる記録を、1つのUTCの時間軸に載せる)、隔離・根絶(表に従って対処し、各対処に根拠を1行)と述べています。

揮発性の順序が要です。メモリはプロセスを殺した瞬間に消え、プロセス一覧と開いているソケットは再起動すると消え、ディスクのファイルはおおむね残ります。そのため、「プロセスを今殺すべきか」という問いの答えは、ほとんどいつも、「メモリを取得したあとに」です。

逆に、資格情報の取り消しは、先送りできません。ノード1台を止めても、そのノードから漏れた証明書は、クラスターのどこからでも使われ続けます。Kubernetesで、ノードのアイデンティティはsystem:node:<이름>(プレースホルダーは名前です)で、Nodeの認可モードが、そのアイデンティティが何を読めるかを決めます。そのノードにスケジュールされたPodが使うSecretがそこに含まれるので、ノード1台の資格情報は、そのまま、そのノード上のワークロードの秘密のすべてです。

タイムラインを作るときは、形式を先に決めておくほうがよいです。時刻はUTCのISO 8601で、ソース名は決まった単語で、アクターと出来事をそれぞれ1列に。そうしておけば、複数の人が分担して書いても合体でき、並べ替えるだけで、物語が見えます。

対処表は、インシデントごとに新しく書くのではなく、あらかじめ作っておいて、その日の値だけを埋めます。たとえば、次のような形です。

조치           시점    근거
메모리 수집    지금    프로세스를 건드리면 사라진다. 되돌릴 수 없다
네트워크 차단  지금    외부로 나가는 것만 끊는다. 프로세스는 살려 둔다
프로세스 종료  나중    메모리를 뜬 뒤. 지금 죽이면 그 증거가 함께 죽는다
예약 작업 제거 나중    지속화 수단은 원본을 보존한 뒤에 치운다
자격증명 폐기  지금    노드를 꺼도 유출된 인증서는 클러스터에서 계속 쓰인다
노드 재설치    나중    디스크 이미지를 뜬 뒤. 마지막 단계다

このコードブロックの韓国語は、表の見出しが、対処・時点・根拠で、6つの行が順に、メモリの取得(今)、ネットワークの遮断(今)、プロセスの終了(あとで)、スケジュールされたジョブの削除(あとで)、資格情報の取り消し(今)、ノードの再インストール(あとで)を指し、根拠の列は、各行について、元に戻せないこと、証拠の保全の順序などの理由を述べている、という意味です。

表があれば、午前3時に判断することが減ります。判断することが減れば、ミスも減ります。

そして、調査で実際に仕事が進む方式は、ピボット(pivot)です。1つの値(PID、ファイルパス、宛先アドレス、アイデンティティ)をつかんで、ほかのデータで同じ値を探します。ホストのログのPID1つが、カーネル監査の記録につながり、そこで読まれた証明書のパスが出てきて、その証明書のアイデンティティが、APIサーバーの監査ログのuser.usernameと一致します。その連結が、「ノードが侵害された」を「決済ネームスペースのSecretが読まれた」に変えます。

現場での姿

ポストモーテム報告書で最もよく抜ける節が、検知ギャップです。何があって、どう直したかは皆が書きますが、「なぜ3時間、誰も気づかなかったのか」は書きません。ところが、次のインシデントを減らすのは、その節です。ルールがなかったのか、ルールはあったのにアラートが誰も見ないチャネルに行ったのか、ログそのものがなかったのかは、まったく別の処方につながります。

2番目によく崩れるのが、証拠の完全性です。元のファイルを開いてエディターで見ているうちに保存ボタンを押すと、その瞬間、そのファイルは証拠ではありません。コピーを取ってハッシュを残す30秒が、それを防ぎます。

3番目は、報告書が人の名前で終わることです。「担当者がミスをした」で終わる報告書は、翌週に同じ事故を招きます。直すべきものは、たいてい、「なぜそのミスが可能だったのか」の側にあります。そのスケジュールされたジョブのディレクトリに誰でも書き込めたこと、ノードの証明書がワークロードと同じファイルシステムにあったこと、アラートのチャネルに誰もいなかったことです。

4番目は、タイムラインのタイムゾーンが混ざることです。FalcoのアラートはUTCで残り、ジャーナルは画面に見せるときにホストのローカル時間を使い、監査ログの原本はエポック秒です。この3つをそのまま貼ると、3時間のインシデントが6時間に見えたり、順序がひっくり返ったりします。そのため、タイムラインの最初の列は、常にUTCに統一し、元の形式は、必要なら最後の列に付け足します。

次のラボですること

ラボでは、実際のインシデント1件の4種類のデータ(Falcoのアラート、カーネル監査の原本、cronのジャーナル、Kubernetesの監査ログ)を受け取って、調査を一巡します。データを数え、最初のアラートを選び出し、コピーとハッシュで証拠を保全し、4つのソースを1つの時間軸に載せ、ピボットを設定してホストからクラスターに飛び移り、6つの対処の順序を根拠とともに決め、最後にポストモーテム報告書を書きます。ファイルだけを扱うので、ラボのPodで動きます。