JPCERT CSIRTガイドについて
現在、著名な企業や官公庁におけるサイバーセキュリティ侵害に関する報道が、国内外を問わず数多く報道されています。企業や組織の活動においてITの依存度が高まるとともに、ITシステムを狙うサイバー攻撃はより高度化し、その脅威を増している状況です。
情報セキュリティ問題が企業や組織にもたらすリスクへの対応は、もはやシステム管理者だけの問題ではなく、経営者が積極的に関与しなければな問題となっており、情報セキュリティへの対応には技術的に高い専門性だけでなく、業務に対する幅広い知識が求められている状況です。
そのような状況の中で、多くの企業や組織では情報セキュリティ問題への対処を行う機能として、CSIRT（Computer Security Incident Response Team）が設置・運用されており、今はセキュリティへの対応を行うに当たって必要不可欠な機能です。
しかし、多くの企業や組織では、CSIRTの構築を試みているものの、必要な知識や経験が不足しているため、その実現にが難航しています。その結果、情報セキュリティ体制が不十分な状態が続いており、リスク対応能力の向上が求められる状況にあります。
そこで今回は、そのような課題を持っている方に対して、CSIRT構築の必要な観点と具体的に何をする組織・機能なのかをわかりやすく解説していきます。
https://www.jpcert.or.jp/csirt_material/files/guide_ver1.0_20211130.pdf
なぜこのマニュアルを紹介するのか
私がこのCSIRT資料を紹介する理由は2つあります。
CSIRTとはどのような組織なのか、必要なスキルは何かわかりやすく具体的に書かれている
初学者が読んでも理解できるCSIRT構築方法につい載書されている
CSIRTとはどのような組織で、必要なスキルは何かわかりやすく記載されている
CSIRTに関する資料はネットや書籍にいくつかありますが、結成の背景や目的について詳しく書かれた資料は数少ないです。
しかし、この資料は上記の内容も含めてCSIRTについて詳しくまとめられており、初学者でもCSIRTを深く理解できるようになります。ページ数は多いものの、一度目を通すと組織や企業が直面するセキュリティ管理体制の課題やインシデント発生時の対処に向けた取り組みなども見えてきます。
一方で、今後セキュリティ業務に携わる方、社内にCSIRT構築する方へ必要なスキルや考え方についてまとめられています。
初学者が読んでも理解できるCSIRT構築方法について記載されている
一般的にセキュリティに関する資料は専門性が高く、初学者に難しく感じられます。しかし、こちらの資料はセキュリティに携わっていない方でも内容を理解できる資料になっています。
特にインシデント発生時の対応やCSIRT構築方法について論理立てて説明しており、何度も読み返しても学びがあります。
この資料の提供元
この資料の提供元はJPCERT/CCです。JPCERT/CCは一般社団法人コーディネーションセンターと呼ばれており、コンピューラーセキュリティの情報を収集し、インシデント対応の支援やコンピューターセキュリティ関連情報の発信などを行う一般社団法人になります。
この法人は1992年ごろに有志によるボランティア活動に端を発し、1996年に「コンピューター緊急対応センター」として発足しました。その後2003年に中間法人JPCERTコーディネーションセンターとして設立登記され、2009年に一般社団法人コーディネーションセンターに変更され、今に至ります。
この資料はインシデント対応支援の一環として、提供されたCSIRTガイドブックになります。
この資料の内容
この資料は主に以下、7つの項目で構成されています。
1つ1つ順番に説明していきます。
CSIRTとは
CSIRTの必要性について
CSIRTに求められること
CSIRTの位置付け
CSIRTにあらかじめ必要なこと
インシデントハンドリング概論
CSIRT構築方法
1. CSIRTとは
この章では、CSIRTとはどのような組織で実際に発生するインシデントとの関係性について記載しています。
CSIRTとは「Computer Security Incident Response Team ＝ コンピューターセキュリティインシデントに対応するチーム」の略称であり、何ならのインシデントが発生した際に先頭に立ってインシデント対応を行うチームのことです。
では、そもそもインシデントとは何でしょうか。インシデントとは、一般的に「重大な事故に至る可能性のある出来事」を意味しており、その中でも情報セキュリティにおけるインシデントとは、情報の機密性、完全生、可用性（※1）を脅かす事象であり、その結果として事業運営を危うくする可能性のあるものを指します。
例えば、コンピューターウイルスへの感染やサービス運用妨害攻撃、またそのような事象につながる弱点探索（スキャン）などもインシデントに該当します。
上記のように定義されるインシデントに対してCSIRTが行うのが「インシデント対応」です。
具体的には以下の一連の行動を指します。
インシデントを検知する、あるいはその報告を受けることによりその発生を認知し、影響の拡大を防ぐ
情報を収集して分析を加え、インシデントの全体像や原因について把握する
復旧措置や再発防止のための措置をとる
ここで重要になってくることは「インシデントの発生を完全に回避する予防策は存在しない」ことです。
かつての情報セキュリティ対策は、ウイルス対策ソフトやファイアーウォールの導入といったインシデントを未然に防ぐことが主眼に置かれていました。もちろん適切な事前対策によってインシデントの発生確率を減らすことは可能です。しかし、実際に発生したインシデントの原因を分析すると次のようなものが多く発生しています。
（1）人為的ミス
パッチの適応忘れ、システムソフトウェアの設定の誤り、システム運用やデータ取扱いにおける人為的ミスがインシデントにつながることは珍しくありません。人間である以上、このようなミスを完全に無くすことは難しいです。
（2）対策のない脆弱性の対応
発見された脆弱性の全てに対してパッチが適応されるわけではありません。何らかの理由により製品開発者がパッチを提供しないケースや発見された脆弱性情報が流通するケースもあります。
そのような回避策もない脆弱性が悪用された場合、防御することが難しく、深刻なインシデントの発生につながることがあります。
（3）技術的な対応の世界
システムの仕様上、特定のインシデントの発生を防ぐ機能がない、つまり根本的にシステムを入れ替えない限り、対応が不可能な場合はあります。そのような製品を入れ替えず使い続けることはインシデント発生のリスクを高めることになります。
（4）セキュリティポリシーに定義されず個人の解釈に依存する事項の存在
セキュリティに関わる事項は多数に渡るため、すべてのセキュリティポリシーに定めることは事実上不可能であり、個人の解釈や理解によって左右される曖昧な事項がどうしても残ってしまいます。
そのような曖昧さのために適切な対応がとられず、その結果期待されるセキュリティレベルを維持できない可能性があります。
これらの原因から分かるように、どれだけ事前に対策を講じても、インシデントが発生する可能性はあります。
そこで、適切なインシデント対応として求められることは、インシデントの発生を完全に防ぐことは不可能であるという「事故前提」の意識の下、インシデント発生時に「いかにして被害を最小限にとどめるのか」、発生後「いかにして速やかに復旧するのか」といった点が求められます。
そのためには、インシデントが発生する前からあらかじめインシデント対応のための体制も構築することが必要となります。
現在では、攻撃の潜在化や攻撃手法の高度化、またソフトウェアの未知の脆弱性を悪用したゼロデイ攻撃、高度サイバー攻撃（APT）の増加によってインシデント対応には、技術的に高い専門性だけでなく、業務に対する幅広い知識も必要になってくるため、システム管理や運用のみを行う部門だけでは対応が難しい場合が増えています。
このような背景から「組織的なインシデント対応」が必要となっており、それを実現する組織がCSIRTになります。
CSIRTは必ずしも「インシデント対応を専門に行う部署」である必要はなく、あくまでも「インシデント対応を行う機能」としてのCSIRTが必要になります。例えば、「部署横断型のCSIRT」や「個人としてCSIRT機能を持つ個人型CSIRT」などがあります。
サービス対象とCSIRTについて
CSIRTにとって重要なことは、まず「どこで発生したインシデント」に対応するのか、言い換えるとCSIRTの活動範囲（サービスが提供される対象）がどこであるのかを明確に定義する必要があります。
現在のCSIRTの機能は、サービス対象によって次のように分類されます。
組織内CSIRT
国際連携CSIRT
コーディネーションセンター
分析センター
ベンダーチーム
インシデントレスポンスプロバイダー
この分類は一例に過ぎませんが、他にも様々な観点で分類されることはあります。上記について詳しく説明していきます。
（1）組織内CSIRT
サービス対象はCSIRTが属する組織の従業員、システム、ネットワークなど。組織に関わるインシデンに対応する企業内CSIRT
（2）国際連携CSIRT
サービス対象は、そのCSIRTが置かれる組織や国の地域となり、このようなサービス対象をもつCSIRTは、国や地域を代表して、他の国やインシデント対応のための連絡窓口として活動する
（3）コーディネーションセンター
サービス対象は、協力関係のある他のCSIRT。インシデント対応においてCSIRT間の情報連携、調整を行う。
企業グループ間のコーディネーションセンターとして各グループ企業のCSIRTとの連携や調整機能を担うこともある。
（4）分析センター
サービス対象は、そのCSIRTが属する組織や地域であり、インシデントの傾向分析やマルウェアの解析、侵入等の攻撃活動の痕跡の分析を行い、必要に応じて注意喚起を実施する。
（5）ベンダーチーム
サービス対象は自社製品の利用者。自社が開発・提供する製品の脆弱性に対応し、社内の関係部門と連携してパッチの作成やアップデートを行い、製品利用者への情報提供と注意喚起を行う。PSIRT（Product Security Incident Response Team）とも呼ばれており、ベンダー企業によっては、組織内CSIRTの中にこの機能を持たせるケースもあれば、組織内CSIRTから独立してPSIRTを設置するケースもある。
（6）インシデントレスポンスプロバイダー
サービス対象は、サービス契約を結んでいる顧客。組織内CSIRTの機能またはその一部を有償で請け負うサービスプロバイダーやセキュリティベンダー、SOC事業者などが該当する
2. CSIRTの必要性
CSIRTを構築することで得られるメリットには次のようなものがあります。
（1）情報セキュリティインシデントに関する情報の一元管理
CSIRTが存在しない場合、組織内で発生したインシデントなどの情報セキュリティに関する情報が各部署からまとまりのない形で経営層に伝達されるため、専門知識のない経営層が状況を整理しなければならなくなります。
CSIRTはそういった組織内のギャップを吸収し、インシデントや情報セキュリティに関する情報の集約と組織内の関係者に適切に伝達する機能を担い、効果的な対応と対策がなされていることを支援し、組織内における情報の流通を防ぎます。
（2）情報セキュリティインシデントに関する組織内外との統一された窓口
CSIRTが存在しない場合、自組織で発生したインシデントに関して外部からの問い合わせを受ける窓口が一元化されず、複数の窓口に届けられた個々の情報間の連携、関連付けが難しくなり、結果としてインシデントの対応が遅れる可能性があります。
CSIRTはインシデントの報告や関連する問い合わせについての社内外に向けた窓口として機能することで、情報を集約し、関連付けを行うことで、社内外に発するメッセージを統一化します。
（3）インシデント対応に関係する外部組織との信頼関係の構築
インシデントに関する情報を他組織と共有することで自組織のインシデント対応に役立てることができます。
しかし組織にとって軽微な情報を含む可能性のあるインシデント関連情報を外部に出すことが一般的に難しいことであり、関係者以外に情報を漏らさないという「信頼関係」が必要になります。
CSIRTが存在しなければ、他組織にとって情報交換の相手は各部署の担当者となり、さらに案件ごとに異なる部署と情報交換することになれば、提供した情報が相手の組織内で適切に扱われているのか確認をもつことができなくなり、結果として信頼関係の構築は難しくなります。
しかし、CSIRTが存在すると、外部に対する「信頼の窓口」として機能することで組織間の信頼関係の構築が容易になります。
3. CSIRTに求められること
CSIRTにとって最も重要なことはサービス対象間の「信頼関係」です。
なぜなら、CSIRTが扱う情報はインシデントそのものに関する情報をはじめ、社内の機密に該当するものが多いためです。
各主管部署は機密情報を適切に扱わない「信頼」できないCSIRTにインシデント対応を依頼することができず、結果として、自組織でインシデント対応することになります。
また、CSIRTにとって必要なことは信頼関係だけでなく、円滑なインシデント対応を行うにあたり、他のCSIRTや関連組織との情報共有や情報連携が必要になります。
他の組織との情報共有によって、今世の中でどのようなインシデントが起こっているのか、その原因や対策、攻撃活動を検知・防御するための手掛かりといったインシデント対応に必要な情報を把握することで自社で同様のインシデントが発生した際に速やかに対応することができます。
また、他のCSIRTや関連組織と連携し支援を得ることによって、効率的な対応を行い復旧までのコストを軽減することができます。
しかし、インシデントに関する情報は機密情報に該当するものが多く、関係者以外に情報を漏らさないという信頼関係が必要です。
そして、信頼関係に基づくコミュニティー=「信頼の和」を形成することによって共有できる情報の輪が広がり、結果、CSIRTの活動に大きな効果を生みます。
3.2 信頼の和の作り方
サービス対象から信頼を得るためには、まずCSIRTの存在を彼らに認知してもらうことが必要です。
具体的には、サービス対象が閲覧できる（社内）Webサイトを設定し、CSIRTの活動内容や情報を掲載します。
また、普段からサービス対象との情報共有が必要です。
CSIRTは常に、サービス対象で発生する可能性があるインシデントおよび関連する技術情報を収集し、その情報が社内システムに関わる場合は担当部署に対して情報を提供します。
また一般社員にも必要な情報があれば、社員向けに注意喚起を行います。さらにセミナーやミーティング、インシデント対応演習などを定期的に行い、CSIRTの活動を普段から社員に示すことで信頼を得ることができます。
CSIRTの情報共有で必要なことは「信頼関係」です。この信頼関係は「顔が見えない」形でのコミュニケーションでは形成できません。直接、対面での意見交換などを通じて、どのCSIRTにどのようなメンバーがいて、どのような活動をしているのか、またどのように情報がやり取りされているのかといったことを互いに共有し理解することが求められます。
多くのCSIRTコミュニティーの会合では他組織のCSIRTと直接意見交換する機会が得られるので、相互理解する場として積極的に利用するのが良いです。
特に、密な情報共有を望むCSIRTに対してはメンバー全員と互いに顔見知りになっておく場合もあります。しかし実際に全てのCSIRTのメンバー全員と顔見知りになることは難しく、メンバーの担当任務の内容によって外部に顔を知られては困る場合もあります。
また複数のメンバーが別個に対外的に活動することで、CSIRTとして統一された対外的コミュニケーションが難しくなる場合もあるかもしれません。
そこで、通常CSIRTはPoC（Point of Contact）と呼ばれる「代表者」を用意して、そのPoCがCSIRTの「顔」として他のCSIRTとの信頼関係を構築したり、コミュニティーとの情報共有の窓口としての役割を果たします。
また、PoCには、あらかじめCSIRT間で取り決めたフローでは対応できないような想定外の事態が発生した場合の「柔軟性のある」連絡窓口としての役割もあります。
PoCは、CSIRTの顔としてコミュニティーとの信頼関係を構築するために、国際会議や意見交換会などの、コミュニティーのメンバーが集う場に継続的に参加し、積極的に交流を深め、信頼関係を構築および維持するように努める必要があります。
また、PoCに求められるものは、高いコミュニケーション能力とコミュニティーで得られた情報を的確に処理する能力、CSIRTの「顔」としての役割を果たせるだけの十分な知識、そしてセキュリティを扱うものとして高い倫理観などが必要です。
注意が必要なことは、PoCはそれぞれ組織のCSIRTを代表する立場であるものの、ここで述べている信頼関係は、そのPoC担当者が所属する組織の信頼によるものよりも、PoC担当者個人の信頼に根ざす割合が大きいです。
もしPoC担当者が何らかの理由で不在となったりした場合、一時的にでも信頼関係が損なわれることを避ける必要があります。
後任者への適切な引き継ぎはもちろんのこと、普段から可能な限り複数のCSIRTメンバーが他組織との関係を保ち、信頼関係を増やしておくことは大切になります。
3.3 CSIRTのコミュニティー
CSIRTによるコミュニティーには次のようなものがあります。
（1） FIRST（Forum of Incident Response and Security Teams）
CSIRTによる国際フォーラム。FIRSTが定めたルールに沿うCSIRTならどのようなCSIRTでも参加が可能
（2）APCERT（Asia Pacific Computer Emergency Response Team）
アジア太平洋地域のNatinal CSIRTによるフォーラム。APCERTが定めたルールに沿うCSIRTのみ参加可能
（3） 日本シーサート協議会
日本国内のCSIRTによるフォーラム。日本シーサート協議会の使命名及び活動内容に賛同し、かつ協議会から得られた情報を適切に扱うことができる日本国内で活動するCSIRTであれば参加可能
上記3つのコミュニティーはいずれも新規参加にあたって既存メンバーによる推薦を必要としています。
これは文字通り「信頼の輪」の考えに基づくものです。
4. CSIRTの位置付け
CSIRTは、組織によってサービス内容が異なるだけでなく、そのサービス内容によって実装も大きく異なります。
ここでは、CSIRT（及びその機能）を組織としてどのような位置付けにすべきか、いくつか例を挙げて紹介します。
（1）経営直下にある場合
経営層から委醸された権限の下、各部署と連携します。
（2）経営直下にあるリスク管理委員会の下にある場合
リスク管理委員会から委醸された権限の下、各部署と連携します。
（3）経営直下にあり、リスク管理委員会と並列している場合
経営層から委醸された権限の下、各部署及びリスク管理委員会と連携します。
5. CSIRTにあらかじめ必要なこと
ここでは、CSIRTを構築するにあたり、あらかじめ決めておかなければならないこと、やらなければならないことを説明します。
5.1 サービス対象の明確化
1.2で説明したようにCSIRTにとって重要なことは、まず「誰のインシデント」に対応するのか、つまりCSIRTにとってサービス対象者（活動範囲）が誰であるのかを明確に定義することです。
5.2 活動目的の明確化
CSIRTの活動目的を明確にしておく必要があります。被害の最小化、被害から迅速な復旧など、いくつか目的が考えられますが、それらのうち、どの目的を優先するのかといった優先順位づけを行います。
あらかじめ対応マニュアルを用意していない「予期せぬインシデント」に遭遇した時も速やかに対応できるようになります。
また、CSIRTの活動目的を明確にすることで、そのCSIRTが提供すべきサービス内容やCSIRTの具体的な実装も変わってきます。
5.3 サービス内容の定義
CSIRTは、サービス対象に対して提供するサービス（活動内容）を定義し、サービス対象にあらかじめ告知しておく必要があります。
提供するサービスは、サービス対象のニーズに応じて異なります。
CSIRTのサービスを定義する際には、サービス対象に対するヒアリングや過去に実際に発生したインシデントや今後想定されるインシデントを可能な限り詳細に分析しておく必要があります。
また技術の進歩、取り巻く環境や変化に応じて、適宜サービス内容を見直し、再定義することも重要です。
実際には、CSIRTによってサービスリストの種類及びそれらの定義づけが異なります。
提供するサービスを決める時に、もう１つ重要な点があります。
当然のことながらCSIRTのリソースは無限ではありません。したがって全てのインシデントに対応できるとは限らないので、トリアージ（優先順位付け）の基準があらかじめ定めておく必要があります。
そして、定義し分類されたそれぞれのインシデントごとの対応マニュアルを作成します。
5.4 通信チャンネルの設置
対応するインシデントの内容によっては、CSIRTメンバーだけで対応しきれない場合もあります。まず当事者であるサービス対象からの情報提供などの協力と連携が重要であることはもちろん、サービス対象でない該当インシデントの当事者との連携が必要なこともあります。
そこで、サービス対象および該当インシデント関係者との間の通信チャンネルを用意し、その方法を明示しておくことが奨励されます。
まず、CSIRTのWebサイトのURL、連絡用メールアドレス、電話番号などの通信チャンネルに関する情報をサービス対象に確実に通知します。また、サービス対象以外からの連絡（通報、問い合わせ）が想定される場合は、組織のWebサイトなどに連絡方法を明記します。
6. インシデントハンドリング概論
6.1 インシデントマネジメント、ハンドリング、レスポンス
CSIRTがインシデントに対して行う業務（広義のインシデント対応）は大きく3つのステージに分かれます。
（1）インシデント発生前
CSIRTが平時行う日常業務であり、インシデント発生に備えた準備の活動です。
CSIRTの日常業務として、一般的にセキュリティ対策と呼ばれることの多い、ウイルス検知ソフトやファイアーウォールの導入など、インシデントの未然防止策の実施をイメージすることが多いかもしれません。
しかし、CSIRTの日常業務として最も重要なことは、インシデントに関する情報の収集とそれが自組織のシステムに与える影響の分析、そして自組織のリスク許容度を評価することです。
日々大量に提供されるセキュリティ関連情報の中から自組織のシステムに関連するものをピックアップし、現時点で該当システムが晒されている脅威を把握し、必要な対策を講じることでインシデントを未然に防ぐことができます。また、インシデントを未然に防ぐことができなくとも、被害を最小限に抑えたり、被害から復旧したりすること上で必要な情報を蓄積することで、対応を速やかに行うことができます。
また、インシデント発生時に備えて、異常を速やかに検知する仕組み（装置や体制）を導入し、インシデント検知後の対応マニュアルを整備しておくことが重要です。
（2）インシデント発生時
インシデント発生時は、被害を最小化し、速やかな復旧に繋げることを目的とする活動です。
まず大切なことは、インシデントを速やかに検知することです。CSIRTから自らが検知するための仕組みが必要であることはもちろん、外部からの通報を受ける窓口を設置する必要があります。
またCSIRTの資源は無限ではありません。同時に複数のインシデントに対応しなければならない場合には、個々のインシデントに対して、あらかじめ決めた基準に従って、トリアージ（優先順位付け）をします。
検知されたインシデントが高度サイバー攻撃（APT）である可能性の場合、攻撃によるリスクがどの程度になるのか。自組織でどの程度リスクを許容できるのかによって、対応方針を検討する必要があります。
（3）インシデント発生後
インシデントから復旧し、再発を防止することを目的とする活動です。
インシデントによる被害から復旧し、システムを元の状態に戻しても、インシデントの原因を取り除かなければ、同じインシデントが再発してしまいます。そこで、まず行わなければならないことはインシデントの直接の原因追及です。インシデントの原因には、パッチの適応忘れや設定間違いといった初歩的なミスから、未知の脆弱性の悪用まで、さまざまなものがあり、場合によっては外部の専門機関に判断を委ねなければならないほど複雑で究明が困難なケースもあります。原因を追及し、その原因を取り除くことまでは、元に戻しただけの状態のシステム運用に移すことは大変危険です。
ここで重要になってくることは、原因追及に必要な情報収集であり、特に外部の信頼できる組織の情報共有が有効に働く場合もあります。
原因を追求し、同じインシデントが発生しない対策（パッチ適応、フォームウェアの更新、設定変更など）を講じた上で、システムを運用に戻します。またインシデント対応時に参照したマニュアルや手順書をレビューし、インシデント対応の進め方に問題がなかったかを確認し、必要に応じて修正・改訂します。
このようなインシデントに対して、CSIRTが行う一連の業務をまとめて「インシデントマネジメント」と呼びます。また、このうち「（2） インシデント発生時」と「（3） インシデント発生後」のような、実際に発生したインシデントに対して行う一連の作業を「インシデントハンドリング」と呼び、特にその中で、インシデントを対応する業務を「インシデントレスポンス」と呼びます。
ただし、これらの区別が厳密なものではなく、CSIRTによって異なります。
以降は、これらのうち、実際に発生したインシデントに対して行う「インシデントハンドリング」について説明します。
6.2 インシデントハンドリングの機能
インシデントハンドリングは「インシデント情報のトリアージ」「解決に向けた活動」「注意喚起及び啓発活動」「インシデント対応以外の要請への対応」の4つの機能から成り立っています。
（1）インシデント情報のトリアージ
CSIRTが対応すべきインシデントに対して一次分析を行い、その内容や深刻度、緊急度などから対応の優先順位を行います。この順位付けの判断基準はあらかじめ可能な限り詳細に定めておく必要があります。
（2）解決に向けた活動
該当インシデントに関連したWebサイトの運営者や他のCSIRT、必要に応じて専門家などと情報をやり取りし、必要な対応に繋げます。
（3）注意喚起及び啓発活動
インシデント被害の拡大帽子などを目的にサービス対象に対して情報共有と注意喚起を行います。
（4）インシデント対応以外の要請の対応
インシデント対応の結果を該当インシデントについてCSIRTに対応を要請した方や関係者（上位組織や監督官庁など）に報告したり、必要に応じて広報部門を通じて情報を公表したりします。
6.3 インシデントハンドリングの流れ
代表的なインシデントハンドリングの流れを示したものが次の図になります。
監視システムなどからの情報や外部からの通知などで検知または認知したインシデントを必要に応じた外部との情報共有などに基づいてトリアージを行います。その後、実際に対応すべきインシデントか否かを判断します。
対応すべきインシデントに対しては、状況の把握、分析を行い、対応計画などを策定します。
脅威の排除とインシデントの範囲特定のどちらを優先するのかを判断して対応計画に盛り込みます。
次に策定した計画に基づいて対応を行い、抑制措置や範囲特定を行います。その後、実施した対応や対策が適切であったのかを判断して、必要であれば、改めて状況の把握と分析を行い、対応計画を練り直します。
このような「繰り返し」の結果として最終的な解決に導きます。
7. CSIRT構築にあたって
7.1 CSIRTメンバー
インシデントがITに基づくものであるものであれば、CSIRTのメンバーにはITに関する技術的な専門知識は必要になります。しかし、そのような専門知識やIT分野における経験は、必ずしもCSIRTメンバーになるものへの必須要件にはなりません。
これまで説明したように、CSIRTに最も必要な「信頼」を維持し、速やかに的確にインシデント対応するためには、関係者とのコミュニケーションが必要になります。
従って、CSIRTメンバーに必要とされるのは、サービス対象をはじめとした社内外の関係者とのコミュニケーションを適切に取ることのできる能力、そして「個人プレイ」に走ることなく、チームメンバー間で情報を共有し、「チームプレイ」で動ける能力です。
また、CSIRTメンバーの心得として、「サービス対象に対して情報セキュリティを担うものとしての模範たる姿勢を示すこと」が求められます。
これがなければ、CSIRTに対するサービス対象からの信頼を獲得し維持することはできません。
7.2 設備
CSIRTが扱う情報の多くは機密情報です。従って、その管理には、十分なセキュリティ対策が必要です。ここでは一般的なセキュリティ対策の他に、CSIRTに特徴的な設備としてCSIRTで用いられているものとして一例を紹介します。
（1）執務スペース
セキュリティ上安全に保障すべきエリアを明確に定義（レベル分け）し、保護の必要のないエリアとは完全に分離します。
一般的に、保護されたエリアへ入るには物理鍵以外の認証方法が使われます。例えば、多くのCSIRTでは、生体認証やICカード、暗証番号などが単一もしくは複数の組み合わせで用いられます。
（2）通信設備
インターネット（電子メールなど）
サービス対象や外部からの連絡を受け付けるアドレス宛に送られたメールは、複数のCSIRTメンバーが何らかの形で確実に見れるようにしておきます。また暗号化及び電子署名付きメールが使えるようにしておきます。なお、CSIRTのコミュニティーではPGP/GnuPGが標準になっています。
電話及びファックス
CSIRTメンバー以外がアクセスすることがないように、CSIRT以外の業務エリアとは物理的に切り離された（アクセスに何らかの認証が必要）場所に電話機及びファックス装置を設置します。
常に緊急時の連絡が可能な電話番号を用意します。多くの場合、CSIRTのPOC担当者の携帯電話番号につながるようにしておきます。
（3）データ管理・破棄
機密情報に関しては、紙やCD-Rなどの物理的なものは耐火金庫、電子データは暗号化ファイルシステムを用いたハードディスク上に保管しておく必要があります。また、物理データの破棄用に、紙やCD-Rを粉砕できるシュレッダーを用意し、さらに大量の紙データの溶解処理やハードディスクの物理破壊を外部業者に委託する手順を定めておきます。
（4）インシデントトラッキングシステム（ソフトウェア）
一般的にCSIRTではインシデントの対応進捗状況を管理するシステムが使われています。このようなトラッキングシステムとして、オープンソースのソフトウェアであるRTIRなどが有名ですが、多くのCSIRTでは独自に開発したシステムが使われています。
感想と共感
ここまで長々と記載してきましたが、このマニュアルと読んだ感想として、主に３つの観点で記載したいと思います。
1. 初学者でも理解できるように記載されているのか
2. このマニュアルをみて、実際の各組織で当てはめてCSIRTを構築することができるのか
3. セキュリティの知見を高め、実業務に活かすことができるのか
1. 初学者でも理解できるように記載されているのか
このマニュアルでは、セキュリティ初学者にとってわかりやすく記載されており、インシデントやその種類、インシデントを対応する機能まで丁寧に説明されています。
特にCSIRTについて丁寧かつ詳細に説明しているため、チーム構築の背景から理解を深めることが可能です。しかし、この資料を読んだだけではセキュリティの実務にすぐに対応できるわけではありません。この資料をセキュリティの入門書として活用し、他の参考書や記事と併せて読むことで、さらに理解を深められると思います。
2. このマニュアルをみて、実際の各組織で当てはめてCSIRTを構築することができるのか
この資料を読むことで、おおよその組織でCSIRTの構築することができると思います。多くの企業では、この資料に記載された組織体制を採用しているため、この型を参考にしてCSIRTを構築することができます。
しかし、一部例外はあると思っており、従業員極端に少ないスタートアップ企業やベンチャー企業では、複数の部署を掛け持ち・役職も兼務している可能性もあるため、一度自組織の環境を吟味しながらCSIRTの構築をする必要があります。
3. セキュリティの知見を高め、実業務に活かすことができるのか
実業務に活かすことができるのかについてですが、あくまでこの資料はセキュリティ初学者や入門者に向けての色合いが強い資料です。そのため、有識者にとっては知って当たり前と思われることも多々記載されています。まだセキュリティに馴染みのないかたにとって、セキュリティの知見を高められますが、実業務に活かすにはより細かい知識が必要になります。
この資料はあくまで入門書として利用いただき、より深く知識を高めるために他の教材や資料を参考にすることもお勧めします。
独自の観点
この資料を読んで私が感じていることは２つあります。
経営層のセキュリティインシデントに関する認識
セキュリティに対する開発部門やその他関連部署への意識付け
経営層のセキュリティインシデントに関する認識
セキュリティインシデントはその部署で発生した事象であるだけでなく、場合によっては会社規模で対応する必要があります。
例えば何百万件の情報漏洩が発生した場合、会社の信頼を落とし、収束させるために考えられないほどの費用がかかる場合もあります。
そのため、一部門で発生した事象という認識ではなく、経営層もセキュリティインシデントに対する意識も持って積極的に関与していくことが大切です。
実際に、経済産業省は経営者のセキュリティ意識を高めるため「サイバーセキュリティ経営ガイドライン」を作成し、国全体でセキュリティインシデントの積極的な対応を推進しています。
セキュリティに対する開発部門やその他関連部門への意識付け
この資料でも記載されている通り、その他関連部署との信頼関係を作ることで、インシデント発生時のハンドリングをスムーズに実施することができます。その信頼関係を作っていくためには、まずはセキュリティに対する他部署への意識付けが必要になります。
特に開発部門への意識付けが最も大切であり、彼らはプロダクトやサービスを作成することに注力するため、セキュリティを疎かにしてしまうことが多々あります。
しっかりとセキュリティに対する影響（情報漏洩やシステムを狙った攻撃による影響度）を伝えた上で、彼らを意思疎通をします。
例えば、サービス開発時にセキュリティの観点を入れるためのチェックリストの作成やシステムリリース後のセキュリティ定期点検を実施することにより、決まったこととして対応いただくこともできます。
セキュリティと開発には、ある程度トレードオフの関係がありますが、お互い意識を持ち、しっかりとコミュニケーションを取ることで、信頼関係を築けると思います。
まとめ
色々と長く書いてしまいましたが、ここでまとめとさせて頂きます。
JPCERTが作成したCSIRTガイドはセキュリティ初学者が読んでも理解できる内容となっており、CSIRTに必要なスキル・構築方法がまとめられている。しかし、この資料を読んだだけではセキュリティの実務に対応できるわけではなく、あくまでセキュリティの入門書として活用し、他の参考書や記事と併せて読む必要がある。
この資料は主に7の項目から構成されており、CSIRTの概要からインシデントハンドリング方法までを詳しく説明している。
この資料を読む事で、おおよその組織でCSIRTの構築することができるが、一部例外もあるため、一度自組織の環境を吟味しながらCSIRTの構築を行う必要がある。
セキュリティインシデンについて、一部門で発生した事象ではなく、経営層も強い意識を持って積極的に関与していく必要がある。
CSIRTにとって、信頼関係が最も重要であり、他部署へのセキュリティに対する意識付けやCSIRTの活動を普段から行うことで信頼関係を構築することができる。