情報セキュリティインシデント管理とは

インシデントとは？

一口でインシデント管理と言っても、管理すべきインシデントとは何かを説明することができるでしょうか。まずこの説明をすることができないと、管理すべき対象が不明瞭なインシデント？管理になってしまいます。

よく見受けられるのは、インシデント管理と不適合の管理が入り混じって何を管理しているのか分からない状況になっているケースです。インシデントの原因に不適合が含まれているケースはありますが、貰い事故のようなインシデントもあります。双方に繋がりはありますが、異なる概念だと考えましょう。

情報セキュリティインシデントとは？

情報セキュリティインシデントの定義に正解はありません。そもそも、インシデントの意味自体が各業界、各規格で解釈が異なるからです。しかし、正解かはともかく、ISMSを構築・運用していく上で、情報セキュリティインシデントの定義は必要です。

ISO27001で言う情報セキュリティインシデント管理は、附属書Aで触れられていますが、その用語の説明はISO27000にあります。それによると、インシデントとは簡単に言えば「情報セキュリティ事象のうち、事業運営を脅かしたり情報セキュリティを脅かす可能性が高いもの」とあります。

ここから分かることは、

• インシデントとは情報セキュリティ事象の一部であること
• 情報セキュリティ事象のうち、マイナスの影響を及ぼす可能性が高いものであること

の2点ですが、規格要求の趣旨を鑑みるとA.16 で言うインシデントは「脅かす可能性が高いもの」ではなく「実際に脅かしているもの」と考えたほうが妥当です。単刀直入に言えば、「損害を与える可能性があるもの」ではなく「損害を与えているもの」ということになりますが、前者は予防的に対応することが理想です。

情報セキュリティインシデント管理では何をすべきか？

これらをふまえて、ISMSにおける情報セキュリティインシデント管理は以下のように考えてはいかがでしょうか。

1. 1．全ての情報セキュリティ事象を把握する（実際には不可能に近いので、できるだけ多くのセキュリティ事象を把握する）。
2. 2．把握したセキュリティ事象を分類する（例えば「安全」「要監視（リスクファクター）」「インシデント」といった具合です）。また、段階的にエスカレーションする（「要監視」から「インシデント」への分類変更といった具合です）。
3. 3．要監視はリスク分析をし、必要に応じたリスク対応をする。
4. 4．インシデントは結果対応をしたうえで原因を分析し再発防止をする。

以上です。その際に

1. 1）情報セキュリティ事象の定義と周知
   （「何でも」とするとかえって集まらないことが多いので、最初はある程度例示するとよろしいかと思います。リスク感度が上がってくると、例示しなくても各自の判断に任せることができるようになります）

2. 2）キャッチした情報セキュリティ事象をどのように集約するか
   （書式を用意するとかえって集まらないことが多いです。なるべく網羅的に集めたいので、一次的には簡単な手段で共有することをお奨めします。）
3. 3）誰が分類するか
   （リスク感度が高いのであれば、事象を発見した本人の判断で問題無いのですが、そうでなければ事務局や委員会で分類して、必要に応じて事故報告書を提出させるといった指示を出してはいかがでしょうか。事務局や委員会の負担は増えますが・・・）

といった問題が生じることが多いので、インシデント管理の手順や基準としてご検討ください。