現状でインシデントレスポンスの仕組みなく、SIRTの構築が課題になっている企業も多く存在します。そして、いざ構築するとなると、実現困難な高いハードルを掲げてしまい、機能不全のSIRTになることが少なくありません。
本コラムの第3回では、今後インシデントレスポンスの仕組みづくりを進める企業に向けて、身の丈に合ったSIRTのためのポイントを説明します。
これから構築する企業にとって
一部の大企業を除き、「インシデントレスポンスの仕組みなんてない・・・」という企業が多いのではないでしょうか。中小企業では、ようやく情報セキュリティ管理や対策の社内規程をまとめ、インシデントへの具体的な対応は、次のステップで考えるとの声もよく聞きます。
いずれにせよ、形を整えただけのSIRT（セキュリティインシデントレスポンスチーム：Security Incident Response Team）になってしまうと、インシデントの発生で機能不全になるのがオチです。
これからインシデントレスポンスを考える企業にとって、そんな「残念なSIRT」にならないためには、どう取り組めばいいのでしょう？
いざというと時に本当に使える仕組みになるよう、あるべきSIRTの本質を考えてみます。
そもそもSIRTとは
SIRTの末尾であるTは、Team（チーム）のことです。チームといえば、会社の部や課といった常設の組織ではないように感じます。大企業でセキュリティの専門部門（セキュリティ戦略本部等）がある場合には、インシデント対応を専任する部署があるかもしれません。しかしながら、そうした企業は多くないはずですから、やはり有事の際に都度チームを立ち上げる（臨時の体制イメージになる）のが一般的だと思います。
つまり、（インシデントの疑いを含む）インシデント発生時に、それに対処するチームを結成するのがSIRTの基本です。なぜ臨時のプロジェクトのような体制になるかといえば、あらかじめ専任者なんて置けないのが大きな理由の一つですが、それ以外に次の2つの要因があるからです。
- 影響の拡大に柔軟に対処する
インシデントは、小規模で収まるものから大規模に広がるものまで、その影響はケースバイケースです。特にネットワーク経由でマルウェア感染が拡大すると、同時多発的にいろいろな拠点や部門でインシデントが発生します。そうした状況下では、臨機応変に要員を配置する必要があります。 - 上位組織だけで対処が難しい
インシデントの初期調査や初動対応などのプロセスは、組織の末端でカバーする必要があります。仮にいくつかの支店で、社員のPCから不正アクセスのような事象が発生したとします。そうなると、ネットワークからPCを切り離したり、通常とは異なる症状を確認したり、現場サイドでの対処が求められます。本社からの連絡指示で統制を図るにせよ、現地要員（メンバー）の十分な協力体制がないとできません。
そうした有事の選抜チームで協力するには、あらかじめしっかりとした仕組みが必要です。たとえば、コマンダー（責任者）、マネージャ（調整役）、ハンドラー（実務者）の体制に対し、その役割に応じたメンバーを事前にアサインします。また、対応フローとして、①初動対応、②トリアージ、③原因調査、④暫定・残存対応などのプロセスや手順を明確にしておきます。
また、アサインされた各メンバーは、日常的にインシデントに対処するわけではありません。有事に都度結成するチームだからこそ、万が一のインシデント発生に向けて、定期的に演習訓練をしておく必要があるのです。
構築するには何が必要？
SIRTの体制や対応フローを、社内規程（インシデント対応ガイドライン等）の文書にまとめるのは、そう簡単な話ではありません。ここでは、Who（だれが）とHow（どのように）について説明を加えます。
- Who
だれが、それらの社内規程を作成するかです。一般的には、情報セキュリティ管理の体制（情報セキュリティ委員会等）が主管し、ドキュメントに仕上げていくと思います。具体的には、そこから派生した分科会（SIRT構築プロジェクト等）を設けて、協議を進めることが考えられます。
そこで重要なのは、SIRTのメンバーに加わる（可能性のある）部署から広く参画を得ることです。たとえば、情報セキュリティに明るい部門（情報システム部等）だけで考えると、どうしても専門用語（セキュリティ略語）を多用してしまい、他部門（営業部門等）にとって難解なSIRTになる可能性があります。 - How
全く白紙の状態から、社内規程を作成するのは困難です。たとえば、「SIRTの教科書」のような書籍を購入し、その内容を雛形にするなど、参考にすべきドキュメントが必要です。日本シーサート協議会や日本ネットワークセキュリティ協会（JNSA）、JPCERTコーディネーションセンターなどの業界団体が公開している、各種資料（SIRTガイド等）を活用するのも有効です。
ただし、雛形まるまるコピーといったことではなく、（Whoと同じように）実際に活用するメンバーが十分理解できるよう、シンプルでわかりやすいプロセスや手順にすることが重要です。
また、ある程度の予算確保が可能であれば、外部専門家（セキュリティコンサルタント等）の支援を受けるのも一つの手段です。
身の丈に合った体制がポイント
いろいろ体裁を整えようとすると、インシデントレスポンスの仕組みは、どうしても大掛かりになってしまいます。その理由の一つは、一般的なSIRTの教科書では、理想的な企業（しっかりとした大企業の体制）を背景に記述されているからです。より良い内容を目指そうとするほど、中小企業の身の丈には合わなくなるのです。
「甘ったれのインシデント体制になるのでは・・・」そんなの気にすることありません。ポイントは、自社で決めたルール（SIRTの体制や対応フロー等）が適切に実施できるかどうかです。実施に課題があるようなら、①そもそもルール自体に問題があるのか、②実施そのものに障害があるのか、その見極めが重要です。
- そもそもルール自体に問題がある場合
もし複雑なプロセスや手順になっているようなら、本当にそうしないと対処できないのか、十分内容を見直すべきです。SIRTの教科書ではそうだとしても、それが必ずしも正解ではありません。第2回で紹介した「ECRSの原則」で、よりシンプルにできないか検討します。 - 実施そのものに障害がある場合
最も障害になるのは、関係者の理解が得られないことです。「本当にそんなことする必要があるのか？」「面倒なことばかり押し付けやがって！」なんて空気が感じられると、大きな障壁が待ち構えています。これを何とかするには、セキュリティ意識を高める教育を地道に行うしかありません。時間はかかりますが、少しずつSIRTの意義を浸透させていくのです。
いずれにせよ、インシデントレスポンスの仕組みを構築したら、それで終わりにはなりません。企業を取り巻くセキュリティ環境は、刻々と変化していきます。その仕組みを継続的に改善しないと意味がありません。最初から高いハードルを掲げるのではなく、少し低いところから徐々にスパイラルアップするのが望ましいはずです。
「それだとちょっと物足りない？」と感じるくらいのSIRTからスモールスタート。それが、成功の秘訣になるかもしれません。
次回は
最終回（第4回）は、これまでの内容をまとめ、あらためて「本当に役立つインシデントレスポンスの基本」を整理してみます。これからSIRTを構築する企業はもちろんですが、すでにSIRTがある企業にとっても、より有意義な内容になるよう総括します。
