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

  • セキュリティ

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

小笠原 徳彦
株式会社SHIFT SECURITY(SHIFTグループ会社)技術統括室 シニアセキュリティエンジニア 小笠原 徳彦

お役立ち資料

Introduction

ほぼすべての組織には守らなければならない情報資産が存在します。したがって、それが漏えいしたり紛失したり侵害されたりする問題、すなわちセキュリティインシデント(セキュリティ事故)が発生するリスクは常にあると思ってよいでしょう。
そのようなセキュリティインシデントに対応する(インシデント対応、あるいはインシデントレスポンス)ための組織、それがCSIRT(Computer Security Incident Response Team:シーサートと読む)です。本コラムではCSIRTについて詳しく見ていきましょう。

目次

CSIRT(シーサート)とは

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

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

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

なぜCSIRT(シーサート)が必要なのか?

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

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

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

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

セキュリティインシデントの発生を予め想定する必要がある

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

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

脅威と対策はずっと繰り返される

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

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

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

従来のセキュリティ対策では対策しきれない

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

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

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

CSIRT(シーサート)の役割と対応

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

事前対応

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

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

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

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

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

事後対応

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

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

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

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

CSIRT(シーサート)を設置するには

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

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

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

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

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

関連サービスについて

この記事を書いた人

小笠原 徳彦
株式会社SHIFT SECURITY(SHIFTグループ会社)技術統括室 シニアセキュリティエンジニア 小笠原 徳彦

2015年より株式会社SHIFTにてソフトウェアテスト自動化の顧客導入支援・プラットフォーム開発に従事。加えてSHIFT SECURITY設立に兼務で参画し、初期の標準化や教育などを担当。2019年に同社専任になってからは、開発者向けのソフトウェアセキュリティサービス、スマートフォンアプリ診断手法および社内ツール開発などを主な業務とする。個人としては主にデスクトップ領域のオープンソースソフトウェアの愛好家であり、翻訳やバグ報告、雑誌やWeb媒体への執筆、イベントへの登壇なども行う。隠れた趣味はリバーカヤック。

手掛けたプロジェクト

  • ソフトウェアテスト自動化フレームワーク「Racine」の開発
  • ソースコード脆弱性診断 サービス立ち上げ

など多数

Top