セキュリティ製品がアラートを出したり、利用者から不審なメールの連絡が入ったりしても、その全てが重大なインシデントとは限りません。
まず事象を受け付け、内容を評価して優先順位を決め、必要な対応を行います。その後、状況に応じて関係者への報告や情報公開を組織として判断します。
SGシラバス Ver.4.1の「要求される知識」では、インシデントハンドリングを検知／連絡受付、トリアージ、インシデントレスポンス（対応）、報告／情報公開の順で示しています。
読み終えるころには、事例が4段階のどこにいるかを見分け、段階を飛ばした対応になっていないかを確認できるようになります。
先に結論：受付の後、対応の前にトリアージ
| 順番 | 段階 | この段階で行うこと |
|---|---|---|
| 1 | 検知／連絡受付 | 監視や利用者の連絡から事象を認識する |
| 2 | トリアージ | 影響や緊急度を評価し、対応の優先順位を決める |
| 3 | インシデントレスポンス | 優先順位に従って実際の対応を進める |
| 4 | 報告／情報公開 | 必要な相手へ何を伝えるかを組織として判断する |
特に重要なのがトリアージの位置です。事象を受け付けた後、実際の対応へ入る前に行います。
「4段階」と科目Bの技能区分は同じ表ではない
4段階は、SGシラバスの「要求される知識」に掲載されたインシデントハンドリングの用語例です。
一方、「要求される技能」の「情報セキュリティインシデントの管理」は、発見、初動処理、分析及び復旧、再発防止策の提案・実施、証拠の収集という別の小項目で構成されています。
したがって、4段階を覚えるときは、科目Bの技能区分全体をそのまま四つに分割したものだとは考えません。
1．情報セキュリティ事象とインシデントを区別する
情報セキュリティ事象は、情報システムやサービスで観測される出来事を広く含みます。
例えば、次のようなものが調査のきっかけになります。
- 認証失敗が繰り返された
- セキュリティ製品が不審な通信を検知した
- 利用者から身に覚えのないメールについて連絡があった
- ログに見慣れない操作が記録された
これらには誤検知、承認済みの作業、操作ミスなどの可能性もあります。
SGの技能区分でも、情報セキュリティ事象の中からインシデントを発見することが求められています。全ての事象を直ちにインシデントと断定せず、対象資産、影響、拡大可能性などを確認します。
2．第1段階：検知／連絡受付
検知／連絡受付は、組織が事象を認識する入口です。
主なきっかけには、次があります。
- 監視システムやセキュリティ製品のアラート
- 利用者、委託先、取引先からの連絡
- ログの点検で見つかった異常
- 外部機関から提供された注意情報
- システムの不審な挙動
受付直後に担当者が独断でファイルを削除したり、端末を初期化したり、社外へ公表したりするのは適切ではありません。
具体的な初動での内部報告、指示、エスカレーションは「初動対応とエスカレーション」の記事で扱います。
3．第2段階：トリアージ
トリアージは、受け付けた事象を評価し、対応の優先順位を決める段階です。
複数の事象が同時に発生した場合、限られた要員を影響が大きく緊急性の高い案件へ適切に配分します。
トリアージの判断材料
- インシデントに該当する可能性
- 対象となる情報資産の重要度
- 機密性・完全性・可用性への影響
- 被害範囲と拡大可能性
- 業務や顧客への影響
- 法令、契約、社内規程への影響
- 対応を遅らせた場合の危険性
単にアラート件数が多い、最初に連絡されたという理由だけで優先順位を決めません。
優先度が低くても対応不要とは限らない
トリアージが決めるのは、主にどれから、どの程度の体制で対応するかです。
優先順位が低い事象でも、必要な確認や処置を行います。「優先度が低い」と「対応不要」を混同しません。
4．第3段階：インシデントレスポンス
インシデントレスポンスは、トリアージを踏まえて被害の抑制や業務回復に向けた対応を進める段階です。
一般には、被害拡大の抑制、原因・影響範囲の確認、原因の除去、復旧、対応状況の記録などが関係します。
本記事では4段階のうち3番目という位置付けまでを扱います。封じ込め、根絶、復旧の具体的な進め方は「封じ込めから復旧まで」の記事で扱います。
5．第4段階：報告／情報公開
報告／情報公開では、対応状況や確認できた事実を踏まえ、取引先、顧客、関係機関、社会などへ何を伝えるかを判断します。
部門担当者が単独で公表内容や時期を決めるのではなく、例えば次の関係者が連携して組織として判断します。
- 経営層
- 法務・コンプライアンス部門
- 広報部門
- 情報セキュリティ部門
- 個人情報保護の担当部門
- 関係する業務部門
確認済みの事実と未確認事項を分ける
原因や影響範囲を推測で断定すると、誤った情報を発信するおそれがあります。一方、全てが確定するまで何も伝えないことが常に適切とも限りません。
その時点で確認できている事実、調査中の事項、利用者に求める対応などを区別します。
法令上の報告対象や期限、委託関係の扱いは、個人情報保護を扱う記事で整理します。
6．基本順序と実務上の往復を区別する
SGの知識問題では、まず次の基本順序を押さえます。
検知／連絡受付 → トリアージ → インシデントレスポンス → 報告／情報公開
ただし、実務が最後まで一方向にだけ進むとは限りません。
- 対応中に新しい事実が判明し、優先度を再評価する
- 被害範囲の変化に応じて追加対応を行う
- 対応途中でも経営層などへ状況を報告する
- 外部から追加情報を受けて調査対象を広げる
したがって、「報告は最終段階で一度だけ行う」「一度トリアージしたら再評価しない」という理解は適切ではありません。
初動・対応中の内部報告と、4段階で示される報告／情報公開を区別します。
NIST SP 800-61 Rev.3でも、現在のインシデント対応を固定的な一方向の流れだけで捉えず、CSF 2.0のDetect・Respond・Recoverを中心に、優先順位付け、報告、継続的改善を組み込んでいます。NISTの区分はSGの4段階とは別のモデルです。
7．科目Bでの使われ方
| 事例の記述 | 該当する段階 |
|---|---|
| 利用者から不審なメールの連絡を受けた | 検知／連絡受付 |
| 複数の事象について影響と緊急度を比較した | トリアージ |
| 被害拡大を抑えるため対象端末を隔離した | インシデントレスポンス |
| 取引先への説明内容と時期を関係部門で検討した | 報告／情報公開 |
判断するときは、次を確認します。
- 事象の認識より前にトリアージしていないか
- 優先順位を決めずに対応へ入っていないか
- トリアージをレスポンスの後へ置いていないか
- 外部公表を担当者が独断で決めていないか
- 基本順序と途中の内部報告を混同していないか
担当者としては、事象を受け付けたら、その場で削除・初期化・公表といった不可逆な処置を行わず、内容と影響を確認して上位者や関係部署へ報告します。優先順位の判断や外部への公表は、担当者限りで決めず、定められた体制で組織として判断します。対応中に新しい事実が判明した場合も、そのつど報告して優先度の再評価につなげます。
よくある取り違え
| 誤った考え方 | 正しい整理 |
|---|---|
| 全ての事象を直ちにインシデントと断定する | 事象の内容や影響を確認して判断する |
| トリアージを検知・受付より前に行う | 受け付けた事象を評価する |
| 対応を始めてから優先順位を決める | レスポンスの前に優先度を決める |
| 優先度の低い事象は対応しない | 対応の順番や体制を決めるものである |
| 公表内容を現場担当者が単独で決める | 関係部門と連携して組織として判断する |
| 報告は最後の一度だけ行う | 対応中にも内部報告や再評価を行う |
| 4段階は実務でも必ず一方向にだけ進む | 新情報に応じて往復・並行することがある |
まとめ
- SGシラバスの要求される知識では、インシデントハンドリングを4段階で示している
- 4段階は、検知／連絡受付、トリアージ、インシデントレスポンス、報告／情報公開
- 科目Bの要求される技能は、発見、初動処理、分析及び復旧、再発防止、証拠収集という別の構成
- 全ての情報セキュリティ事象が直ちにインシデントになるわけではない
- トリアージは受付後、レスポンス前に位置し、対応の優先順位を決める
- 優先度が低いことと対応不要であることは異なる
- 封じ込め・根絶・復旧はインシデントレスポンスの具体的な内容として別記事で扱う
- 外部報告・情報公開は担当者の独断ではなく組織として判断する
- 基本順序を押さえつつ、実務では内部報告や再評価が並行することも理解する
関連記事
- C1-T04：ランサムウェア
- C3-T07：セキュリティ対応組織と外部機関
- C5-T09：ログ管理と監視
- C6-T02：初動対応とエスカレーション
- C6-T03：封じ込めから復旧まで
- C6-T04：証拠保全とデジタルフォレンジックス
- C6-T05：原因分析と再発防止
- C8-T02：個人情報の取扱いルール
本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。
参考資料
- IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
- NIST SP 800-61 Rev.3「Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile」
コメント