インシデントハンドリングマニュアルの感想

2024年10月3日 00:07

現在、日本のみならず世界中でサイバー攻撃が多発しており、世の中の大きな課題となっています。サイバー攻撃は完全に防御することは極めて難しく、万が一、攻撃を受けた場合に備えて対応要領をまとめておく必要があります。対応方法についてネットや書籍でまとめられたものが多いものの、そのまま自社に適応することはできません。とはいえ、１からマニュアルを作ることは困難であるため、網羅的にまとめられているJPCERT作成のインシデントハンドリングマニュアルがあります。今回はそのマニュアルについて説明します。

https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20211130.pdf

なぜこのマニュアルを紹介するのか

私が、このインシデントマニュアルを紹介する理由は2つあります。

CSIRT担当者向けのマニュアルとなっており、わかりやすく記載している
代表的なインシデントを例にあげて、対応の考え方や注意点を記載している

CSIRT担当者向けのマニュアルとなっており、わかりやすく記載されている

こちらのインシデントはンドリングマニュアルは、CSIRT担当者向けのマニュアルとなっています。
CSIRTとはサイバー攻撃によって、セキュリティインシデントが発生した際に対応を行うチームのことであり、脆弱性情報などの収集と分析、インシデント発生時の対応等を行います。
セキュリティに関連するチーム担当者のマニュアルであるため、前提知識として、セキュリティ知識はもちろん、ネットワークやインフラの知識がないと読み進められないものが多いですが、このマニュアルは初学者にも理解できるように記載されています。

代表的なインシデントの例をあげており、対応の考え方や注意点が記載されている

また、具体的なインシデントの例を挙げることで、対応の考え方や対応時の観点がよりイメージしやすい構成になっています。

例えば、DDoS攻撃を受けた際の検知・連絡の受付や優先順位づけを行うトリアージの方法なども記載されており、原因の分析を行うにあたって、日本語で書かれらコンテンツに対して、海外のIPからの攻撃はDDoS攻撃であると例を挙げて記載しています。

それだけでなく、対策時についても記載されており、どのような攻撃を受けた場合にどのような順序で対応すべきなのかわかりやすくまとめられていることもおすすめする点です。

このマニュアルの公開元について

このマニュアルの公開元はJPCERTであり、主にコンピューターセキュリティの情報を収集し、インシデント対応の支援等の発信を行う機関です。JPCERTは1996年に日本情報処理開発協会（JIPDEC）の中に「コンピューター緊急対応センター」という名称で組織化され、2006年に「一般社団法人JPCERTコーディネーションセンター」として名前を変え、活動を行なっています。

特記事項として、JPCERTは日本で初めて、国際的なCSIRTが集まるフォーラムであるFIRSTに参加した機関であり、アジア太平洋地域におけるCSIRTの集まりであるAPCERTの事務局も務めています。

要約

このマニュアルは、自社でインシデント対応マニュアルを作成する際の参考資料として利用することを目的としています。特に、代表的なインシデントを例に挙げて、対応の考え方や注意点の概要を簡潔に説明しています。

基本的なインシデントハンドリングの対応フロー

このインシデントハンドリングマニュアルには以下の流れでハンドリングを実施します。

検知 / 連絡受付
トリアージ（優先順位付け）
インシデントレスポンス（対応）
報告/情報公開

検知 / 報告
検知 / 報告とはインシデントが発生した際に自組織内でどうやって検知するのかその具体例を示しています。

主にインシデント発生を検知する方法は主に2つあり、いかに迅速に検知し、対応を行うのかがインシデントハンドリングを行う上で重要になります

１つ目は、保守作業中の中で発生したり、あらかじめ設置したセキュリティ機器やシステムによって異常と検知する、「自組織内」で検知する方法です。

ここで重要なことは、侵入や改ざんの痕跡を確認するためのインシデント検知に必要なチェック項を用意し、そのチェック項目を明確にしておくことです。また、「異常検知システム」を導入する場合は、誤検知を可能な限り防ぐために「何を持って異常とみなすのか」を整理することが必要になります。

2つ目は、外部からの通報をもとにしたインシデントの発生を「検知」とする方法です。

インシデントが発生した第3者からの報告やセキュリティベンダー等による調査によって、脆弱性が発生した場合、彼らから通報をいただく場合はあります。
そのような場合に備えて、インシデント専用の窓口を用意し、自組織のWebサイトに掲載するなどして公開を行います。

また、インシデントに関する通報は、組織の従業員など、サービス対象からなされる場合もあるため、例え、通報の内容が対応するに値しないものでも、サービス対象者に代わって「判断」するものセキュリティ担当者の役目だと考え、適切な対応が必要です。

トリアージとはインシデントが発生した際に、対応の優先順位付けを行うことを指します。
セキュリティ担当者は限られたリソース（人的、設備的）の中で対応することが多いため、あらかじめトリアージを明確にしておくことで、効率的かつ迅速な対応が可能になります。

トリアージを行う目的は対応のための優先順位付けだけでなく、報告を受けたインシデントが対応するべきものなのか冷静に判断しなければなりません。

「インシデントと思われたものがインシデントではなかった」、「悪意のある者による虚偽の報告」などのインシデントではないものをインシデントとしてみなしてしまったり、自組織とは関係のないインシデントに対応してしまうことで、本来は秘匿すべき情報を無関係の第3者に開示してしまう可能性があるためです。

「冷静な判断」をするためにはインシデントに対して「いつ」「どこで」「何が」「どのように」起こったのか、「関係者は誰か」といった点を整理すると良いです
　※「原因（Why）」の究明は後になります。

具体的なトリアージの流れは以下になります。

得られた情報に基づいて、事実関係を明らかにして対応すべきインシデントなのかを判断する
対応すべきインシデントではない場合は、その判断の根拠を自組織のポリシーなどに照らして可能な範囲で詳細に、報告者や関係者に報告する
対応する、しないに関わらず関係者に速やかな対応を依頼し、情報提供すべきと判断した場合は、注意喚起などの発信を行う
対応すべきと判断した場合は、インシデントを「レスポンス（対応）」の対象とする

インシデントレスポンス対応
インシデントレスポンスとはセキュリティ担当者がインシデントと判断した上で、対応を行うことを指します。

具体的な流れは以下になります。

トリアージの結果、CSIRTが対応すべきと判断したインシデントに対して、事象の分析を行います。
1. 重要な点として、技術的に対応が可能かどうかのを判断します。
対応すべきインシデントではないと判断した場合、その判断を自組織の情報セキュリティポリシーに照らし合わせて可能な範囲で詳細に報告者に回答します。
自組織での対応が難しい場合（外注先でなければ対応ができない）は、主に経営層と連携し、対応計画を策定して、実施します。
1. もちろん、その過程で必要であればIT関連部署との情報共有や連携も実施
自組織での対応が可能な場合は、IT関連部署と連携して、必要に応じて外部専門機関や該当インシデントに関係している可能性のあるサイト（関係者）に対して、対応の支援を依頼したり、必要な情報を提供してもらったりします。
技術的対応の可否に関わらず、対応計画の策定や実施に関しては、必要に応じて関係者を巻き込み、対応の支援を行なったり、必要な情報を提供してもらったりします。
対応計画を実施し終わったところで、改めて問題が解決しているのか否かを確認します。
1. 問題が解決されていない場合は、再度事象の検証を行い、対応計画を策定し、実施
最終的に問題が解決した際には、結果を可能な限り詳細に報告者に報告します。

報告/情報公開
対応計画の策定及び、実施と並行して、メディアや社外に向けたプレスリリース、監督官庁への報告を行います。
その他、組織内部への情報展開なども検討していきます。

事象別特記事項

このハンドリングマニュアルには、各種サイバー攻撃に対しる対応事項が記載されています。

1. DDoS（分散型サービス運用妨害）攻撃
【検知 / 連絡受付】及び【トリアージ】
発生している事象がDDoS攻撃だと判断することが難しく、表面的に見えている事象だけでは、正規の利用者のアクセスが単に集中しているだけの状態と区別がつかないことが多々あります。アクセス元のIPアドレスとアクセス頻度、パケット内容を把握した上で、攻撃を受けているのか判断する必要があります。

【インシデントレスポンス（対応）】
DDoS攻撃に対する技術的な対応は、接続しているISPに依頼するのが一般的です。具体的には以下2つのことを対応いただきます。

特定のIPアドレスからのアクセスを遮断・帯域調整
TCP SYN floodなどの「通信自体が異常」なパケットの遮断

また、上記のうち、以下の項目は「事前対策」としてもある程度有効です。

TCP SYN floodなど「通信内容自体が異常」なパケットの遮断をネットワーク境界上で設定
正常な状態との比較で異常（アノマリ）を検知して、自動的にレートコントロールする仕組みの導入を行う

ISPとの連携については、DoS攻撃を検知してから連絡先を確認するのではなく、平常時にISPの担当者と話し合い、連絡先や連絡する内容を明らかにすることが必要になります。

2. マルウェア感染
最近のマルウェアは発生頻度が高い上に、ウイルス対策ソフトによる検知を回避する技術が進んでいるため、ウイルス対策ソフトでは検知できない可能性が少なくありません。
つまり、100％の感染防止は不可能という前提に立った上で対応を考える必要があります。

【検知/連絡受付】
ネットワークレベルでの検知のためのチェック項目を整理して、それらの項目を自動的に検知する仕組みを導入します。

具体的には、内部から外部への通信をチェックし、ユーザーの意図しない通信や一時的な大量の通信、マルウェアと関係している特定サイトへのアクセスなどがある場合は、マルウェアの可能性が高いと言えます。さらにマルウェアによる通信は暗号化されることもあり、その場合ネットワーク上では通信の内容を知ることができないため、通信先や通信元のアドレス及び通信の頻度などをもとにした判断が必要です。

3 不正アクセス
ここでの不正アクセスとは、「Webコンテンツが改ざんされた場合」と「SQLインジェクションに代表されるWebアプリの脆弱性を悪用された場合」について説明します。

【検知 / 連絡受付】
Webコンテンツの改ざんに対しては、システムの改ざん検知と同様に扱います。
例えば、コンテンツを変更するたびにチェックサムを保存して、定期的に比較をするなど改ざん検知の仕組みを導入します。

Webアプリの脆弱性を悪用したインシデントについては、保守作業の際に発見されることもありますが、IPAやセキュリティベンダーからの通知で知ることも多いため、外部からの通信に対して適切に対応できる体制を準備しておく必要があります。

【インシデントレスポンス（対応）】
対応として、主に2つの観点があります。

Webコンテンツが改竄された場合は、利用者保護の観点から速やかにWebサービスを停止させます。またWebアプリの脆弱性が指摘された場合はさまざまな状況を分析した上で、サービスを停止するか否かの判断をします
ユーザーのPCにマルウェアを感染させた、または顧客の個人情報が漏洩したといった被害を生んだ場合は、被害の拡大を防ぐために、速やかに利用者に対して、事実確認を告知します。外部とのやり取りがある者に対しても、あらかじめ問答集を作成し、組織内の各人が適切な対処ができるように指導します。

4. フッシング偽サイト
ここではフィッシングサイトなど、自組織のサイトを謳った偽サイトの存在を検知した場合の対応について説明します。

【検知 / 報告】
フィッシングサイトの検知は、フィッシングメールを受け取ったユーザなどの外部からの通知によって知ることが多いため、外部からの通信に対して適切に対応できる体制を準備しておきます。

【トリアージ】
検知した偽サイトが本当に自組織を騙ったサイトであるのかを判断します。たまたま似ているだけかもしれないといった可能性も考慮する必要があります。

【インシデントレスポンス】
以下の手順でインシデントレスポンスを行います。

顧客保護の観点からプレスリリースやWebサイトでの告知などで偽サイトの存在と、そのサイトに関する情報（危険性など）を告知する注意喚起を行います。
立ち上がっている偽サイトを停止するには、該当サイト（IPアドレスまたはドメイン）管理者などに停止を「依頼」します。
警察に届出を出します。
フッシング対策協議会へ情報を提供します。

5. APT（先進的で執拗な攻撃）
高度サイバー攻撃の疑いのある活動を検知した場合の対応について説明します。
【検知 / 連絡受付】
APTの検知はJPCERT/CCや外部のCSIRT等の情報共有パートナーからの通報によって認識されることが多いため、通報に対して適切に対応できる体制も準備しておきます。

【トリアージ】
検知した攻撃活動に対して、それが実際にAPTによるものであるのかどうかの検証を実施します。

【インシデントレスポンス（対応）】
検知した活動がAPTによる攻撃であると判断した場合、攻撃リスクと自組織のリスク許容度、攻撃による脅威を直ちに排除する必要があるか、あるいは攻撃の範囲特定を試みるべきなどかについて討議し、その結果に基づいて対応を行います。

感想と共感

このマニュアルを見ると、インシデントが起こった際の具体的な対応方法について分かりやすくまとめられており、セキュリティ初学者でも読みやすいマニュアルだと思いました。

一方で、このマニュアルに限った話ではないのですが、実際にインシデンの対応をしていないとなかなかイメージが湧きにくいのではないかと思います。例えば、何からのシステムにインシデントが発生した場合は、ネットワークを遮断するのか、システム全体を停止させるのか、時と場合によって変わってきます。

より理解を深めるために、自分なりにシミュレーションを行ってみて、インシデント対応を行うことでより理解が深めるのではないかと考えています。

独自の視点

このマニュアルでは実際にインシデントが発生した際の対応について記載されていましたが、お客様への影響度によって対応方針を変える必要があるのではと考えています。
例えば、サービスが乗っ取られ、100万人に影響が出るなど）が発生した場合は、早急に経営幹部へ報告を行い、関連部署を集めて原因追究を行う必要がある一方で、お客様数人に影響が出ているものの、現在外部からのインシデントが止まっており、まず技術部門との相談が必要なものなど重要度によって対応するインシデントが変わってくるのではないでしょうか。

また、主にインシデントハンドリングを行うCSIRTが自社でどのような体制をとっているのかによって、関連部署とのやり取りも変わってきます。
例えば、CSIRTをベンダーチームのような形態で運用している場合、ベンダー企業とのやり取りが必要となるため、自社のセキュリティチームの現状を踏まえながら、インシデントハンドリングを行う必要があります。

まとめ

このインシデントハンドリングマニュアルを読むことで、インシデント発生時の具体的なフローやインシデント対応時の考え方をが学ことができます。
具体的なインシデントハンドリングのフローとして「検知 / 連絡受付」「トリアージ（優先順位付け）」「インシデントレスポンス（対応）」「報告/情報公開」の順で対応を行っていきます。
各種サイバー攻撃に対して対応事項が記載されており、「DDoS（分散型サービス運用妨害）攻撃」「マルウェア感染」「不正アクセス」「APT（先進的で執拗な攻撃）」における対応方法について記載されています。
初学者でも読みやすいマニュアルにはなっているものの、具体的なイメージがしづらいため、実際のインシデントをシミュレーションしながら読んでみると理解が深まります。