インシデント管理とCSIRT
要点と定義
情報セキュリティ事象は、情報セキュリティインシデントと同じ意味ではありません。単独または一連の事象が、インシデントに当たる条件を満たせば分類されますが、すべての事象がインシデントになるわけではありません。出題時に参照されたJIS Q 27000:2014では、この関係が問われました。
組織のインシデント対応体制としてCSIRTを設ける場合があります。CSIRTの構築を支援する資料として、CSIRTマテリアルが挙げられます。 IPAシラバス Ver.4.1では、情報セキュリティ関連組織の用語例にCSIRTを挙げています。IPAシラバス Ver.4.1 PDFの第6頁
コーディネーションセンターは、インシデント対応においてCSIRT間の情報連携や調整を行います。 J-CSIPはCSIRTそのものではなく、IPAを情報ハブとして参加組織間でサイバー攻撃情報を共有する取組です。
デジタルフォレンジックスは、インシデントの調査で証拠となるデータを収集・保全し、調査・分析する活動です。
事故には至らなかったものの、事故につながる可能性があった事例は、ヒヤリハットとして捉えられます。
適用条件と例
事象を見つけた時点で、直ちに全てをインシデントと決めつけず、影響や脅威の可能性などを確認して分類します。たとえば、社内共有フォルダに一時的なアクセス遅延があっても、情報漏えいや不正アクセスの兆候がないなら、それだけでインシデントと断定できるとは限りません。兆候や影響が確認された場合は、組織の手順に従ってCSIRTへの連絡や調査につなげます。
証拠の調査が必要な場合は、ログや端末上のデータを不用意に変更・消去せず、収集と保全を行ってから分析します。たとえば、会計システムに不審なログインがあった場合、担当者が記録を保全し、CSIRTが調査を調整する、といった役割分担が考えられます。
ヒヤリハットの例として、倉庫で台車が通路に飛び出しかけたものの、作業者が気づいて接触を防いだ状況が挙げられます。事故が起きていなくても、原因や再発防止策を検討する材料になります。
誤りやすい点
「事象」と「インシデント」を同一視したり、見つかった事象をすべてインシデントと扱ったりしないようにします。出題時に示されたJIS Q 27000:2014の定義に基づく説明であり、現行規定についての断定ではありません。
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む