CSIRT(シーサート)とは？必要な理由や役割について解説

前述のとおり、CSIRTとはComputer Security Incident Response Teamの略で「シーサート」と呼ばれるのが一般的です。直訳すると「コンピュータセキュリティインシデント対応チーム」となるとおり、インシデント、つまりセキュリティ上の問題としてとらえられる事象が発生した際に対応するチームのことを指します。そのために、業務としては日常的には脆弱性情報などの収集や分析を行い、インシデント発生時には直接的な対応と、社内外の組織との情報共有や連携を行います。

なおCSIRTに関連した組織としてSOC(Security Operation Center)がありますが、この両者の違いは、SOCはインシデント発生の前からインシデント発生の検知までに重きを置いているのに対し、CSIRTはインシデント発生後の対応(マネジメント)に重きを置いていることが挙げられます。こちらは過去のコラムで違いを説明しているのでご一読ください。

SOCについてのコラムはこちら

前述のように、守るべき情報資産があるすべての組織は、セキュリティインシデントのリスクにさらされています。とりわけ大企業や公的組織といった組織は、その保有している情報資産の価値も高く、外部の攻撃者により狙われやすくなっています。

インシデント対応は組織にとって非常に大きな課題であり、ひとたびインシデントが発生すると、サービス継続、復旧、そして法的な対応に追われるなど多大な人的コストが発生します。また直接のコストとしては算出が難しいですが、「あの組織はセキュリティインシデントを起こした組織である」という評判によって損失するビジネスの機会などを含めると損害は甚大です。

しかし、サイバー攻撃の手段は年々高度化・先鋭化しており、インシデントを完全に防ぐことは多くの場合困難です。セキュリティインシデントが起きないような体制を作る一方で、インシデントは起きるものと考え、起きたときの対策と復旧を最適に行うことが求められています。

まさにそのための組織が、CSIRTなのです。

繰り返しになりますが、CSIRTというチームが注目されてきているのは、セキュリティインシデントを絶対に起こさないという仮定をするのが困難だからです。これは、主に事前対応が想定される従来のセキュリティ対策とは異なっている部分です。

「セキュリティインシデントは必ず起きるもの」という考えに立つと、「起きたときにどう動くか」を想定してさまざまな対策を事前に持っておくことが必要とされます。組織がどのような脅威にさらされており、インシデントが起きたときの被害にはどのようなものが想定され、それに対して事後の備えをしておくことが求められます。こういった活動は多岐にわたり、むしろ事前対策よりもしばしば困難です。そのため専門のチームが求められるというわけです。

インシデントを完全に防ぐことが難しい理由は、脅威と対策は常にいたちごっこの関係にあるからです。防衛側が防御を固めたとしても、攻撃側はさらにそれを上回る手段の攻撃をしかけてくる可能性が常にあります。

たとえば、メールによる攻撃を考えてみましょう。数年前まではメール経由の攻撃といえばバラまき型のメールで、日本語などの文面や、外部リンクなどへの不自然な誘導などの拙さも多く、訓練次第で防御できたものでした。しかし昨今では、より洗練された文面や、文脈を踏まえた添付ファイルを用いた標的型攻撃によって、メールによる攻撃が成立しやすくなっています。

このようないたちごっこはメールを用いた攻撃に限らず、その他の脅威(サイバー攻撃)においても同様です。

古典的なセキュリティ対策では、考えられるあらゆる脅威に対して対策を施すことで、セキュリティインシデントをゼロにするべきと考えられてきました。

もちろん、常に完全な対策を行っていけるのが理想的ですが、脅威が高度化・多様化する現代においては、現実的には多大なコストを払っても脅威をゼロにするのは不可能といってよいでしょう。

そこで、ある程度はインシデントが発生するのはやむなし、現実的な対策を取るだけのコスト負担に留め、いざインシデントが発生した時は、そのコストを最小限にしよう、という発想で作られる組織がCSIRTです。

CSIRTの活動はしばしば消防にたとえられます。インシデント発生前の「防火活動」および、インシデント発生時の「消火活動」に分けて考えられます。

先の例でいう「防火活動」にあたります。

まず、技術面では世の中における新たな脅威について情報収集を広く行い、それぞれの対策について事前に調査・研究しておく必要があります。

セキュリティに対する組織内の教育・啓発といった取り組みで、組織内の下部組織（例えば異なる部署や事業所など）に対して、「事故は起こさないと思っていても必ず起きるもの」という意識をそろえることが大事です。

そしてCSIRTが組織内における119番通報のような役割を持っていることを周知しましょう。CSIRTとは、インシデントが発生したときにすぐに通報すれば最適な対応を行ってくれるチームである、といった認知を高めておきます。

また、組織外のCSIRTやその他組織内外のステークホルダーとの連携を深めていく活動も重要です。このような連携は実際にインシデントが起きた際に活用されるものだからです。

こちらは「消火活動」、つまり実際にインシデントが起きてしまった際にそれを「鎮火」させる活動です。

セキュリティインシデントが発生してしまった際は、まずは初期の事態収束化を図ります。事前対応で得られた社内外の連携を生かし、どこに事態を報告すべきなのか、技術的協力を受けるべき社内外の組織はどこか、被害拡大防止のためには何を行えばよいのか、といったことを迅速に判断する必要があります。

インシデントの種類によってはリアルタイムな経営判断が必要となる場合がありますので、特に経営層との連携は重要です。

技術的には開発部署やその部署が委託している外部ベンダー、またセキュリティベンダーの協力を仰ぐ必要もあるでしょう。その場合でも任せきりではなく、最終的なジャッジを行う責務はCSIRTにあります。

インシデント対応時に、迅速かつ正確な判断を求められること、そのために経営層を含む社内外のステークホルダーと平素から強いコネクションを持っている必要があることから、CSIRTにはこれと定まった型はなく、組織の形態や文化に従って構築すべきものです。くわしくは日本シーサート協議会「CSIRT スタータキット」などを参照ください。

日本シーサート協議会「CSIRTスタータキット」 

少なくとも、セキュリティ専門家を一人雇用して事足りる、というものではありません。いざというときに実働ができることを前提に、兼務という形を取ってもよいので複数人によるチームの形をとるようにしたほうがよいです。

この際、セキュリティベンダーなどが提供する各種サービスやコンサルティングなどを活用することも検討してもよいでしょう。しかし大事なのは、繰り返しになりますが、いざインシデント発生時に判断を下すのはCSIRT自身であることです。外部ベンダーやサービス、また他部門の「いいなり」にならないように、経営層からのコミットメントをもらった形で組織づくりをすべきです。

また、当然ではありますが、「インシデントが起きることは避けられないという」考え方によってCSIRTという組織があることと、「避けられるインシデントを避けない」ことはイコールではありません。各部門において、SOCの活用や、脆弱性診断やレッドチーム演習など、事前に行える対策はコストとの兼ね合いでしっかり行うことが大事ですし、その意思決定にはCSIRTが関わるほうが望ましいです。