書評 - 実践 CSIRTプレイブック セキュリティ監視とインシデント対応の基本計画

今週はゆっくりとSplunkの動作確認をしている余裕がないので今週は更新頻度が激低になってしまっています。

先日Interop2018に行った時に見つけて電子書籍で購入した本です。

実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画

 良書だと思います。Ciscoのセキュリティチームが書いた本で情報セキュリティ対策、実務の考え方が詳細に記載されています。しかし同時に一介の技術者には不向きとも言える内容です。この記事では本書の内容に触れつつもCSIRTにおける個人的な考え方を書いていこうと思います。本書ではインシデント管理プロセスを検討するにあたり中核となる4個の質問というものに言及しています。

• 守りたいものは何か。
• 脅威は何か。
• どうやって検知するのか。
• どう対応するのか。

保護対象の決定

一つ目の質問に自信を持って回答できる人はどれくらいいるでしょうか。全てと回答するのもアリですが、守る対象を全てと定めた場合は続く質問に対する回答を実現するために膨大なコストを覚悟する必要があるでしょう。しかし多くの組織では情報セキュリティ対策に投じることができるコストはそれほど潤沢ではないはずです。

私見ですが、ここで言いたいのは守るべき対象を真剣に定義することで、必要な対策とそのコストが明確になります。さらに現状取れる手段では守れないものが洗い出され、今後どう対策を取っていくのか議論することができるようになります。

守りたいものはを定義するには恐らく最低でも部長レベルの判断が必要になるはずです。あなたの組織のグループウェアには守るべき機密情報は含まれているでしょうか。ファイルサーバは？社員PCは？それらはどこにあるのか？上級管理職に許された特別な業務形態はないか？検討対象はたくさんあり、さらに一介の社員やマネージャレベルではアクセスできない機密情報が存在します。守る対象を決めないと対策の検討に移れないことが少し考えるだけで分かるはずです。

レポート

運用者にとってはレポートは非常に重要です。レポートの役割は単体のインシデントの詳細が記録されることは勿論ですが、後日に統計情報の入力ソースとして活用するという役割があります。情シスでは一定周期でのインシデント統計を報告する必要があります。そう考えるとレポートに格納されるべき情報が何であるかがイメージがついて来るのではないでしょうか。

報告を受ける人が最も気にするのは自分の組織に悪影響を及ぼす可能性のあるインシデントがあったかどうかです。例えば公開Webサーバを不正通信から保護するためにIPSを導入したとします。このWebサーバはApacheが使用されていますが特筆すべきミドルウェアなどは他に動作していません。その状態でIPSがTomcatの既知の脆弱性を突いた攻撃を検知しアラートレベルHighでログを出力したとしましょう。しかしこのWebサーバではTomcatは動作していないので特に影響のない攻撃です。

レポートに記載する内容はアラートレベルではなく組織に影響があるかどうかです。そのためIPSが記録したログを少なくとも影響の有る無しで分類する必要があります。さらにそのためにはログを見て影響の有る無しを判断するためのナレッジが必要になります。技術者はこの部分に特に注力し、必要なログを適切なレベルに分類する作業が必要になるでしょう。

様々な状況を示すコードが定義されレポートの定型が定まったら、次はレポート出力の自動化を目指していく形になります。(軽く書きましたが超大変な仕事です。一千万円ではきかないようなレベルの人材が必要と思われます。)実はここまでできてしまうとあとはレポート発行ツールの使い方の問題なので必要な知識レベルの質は大きく下がります。

インシデントの調査

本の中で具体的な脅威検出についてかなり言及しています。とは言え攻撃の一例なので、この内容を参考に色々なケースへの適用を考えていく必要があるでしょう。

例えばActiveDirectoryへの認証ログを考えてみましょう。ユーザ認証ログが残りその中に失敗があっても特におかしいことではありません。しかし認証に何度も失敗しているのがAdministratorアカウントだった場合はどうでしょう。もちろんパスワードを忘れて手入力を繰り返して失敗している可能性があります。しかしマルウェアがブルートフォースアタックをしている可能性もあります。個人的にはこのケースでは5回連続失敗あたりからアラートを出すようにログサーバなどで仕掛を作っておくのが良いと思います。

IPS製品によってはこうした攻撃を検知してくれる可能性もありますが、必ずしも全てのサーバにIPSを仕掛けることが可能とは限りません。攻撃者の手法を学び、自分の組織に合ったセンサーを作っていく必要があります。

不幸にも攻撃と判断する基準を超える挙動が検知された場合はその挙動をした要素(大抵は端末のIPアドレスや利用者のユーザID)が他に何をしていたか調査することになります。まず見るのはファイアウォールのトラフィックログやxFlowコレクタの状況だと思います。そこで見慣れない宛先と通信している場合はマルウェアに感染している、または内部不正を働いている可能性が急激に増加します。

重要なのは、自らの組織に導入されているセキュリティ装置やログ集積装置を使った調査シナリオを明文化しておくことです。これにより高レベルでないフォレンジック作業を手順化することができます。

他

情報セキュリティに関する体制作りに関心のある人は読んでみて損はないでしょう。丸投げ気質の人には多分有効活用できないですが、逆にこうした内容を読んで関心を持つ人もいるかもしれません。SI的な仕事をする人にもおススメします。システム構築の時にどのような管理設計を行うと客に喜ばれるのか、どのような機能を持つ製品が一連の流れに効果的に寄与できるのか、流れをスムーズに進めるにはどのようなログ基盤を作れば良いのか、参考になる点は多々あるはずです。