第５０号コラム：佐藤 慶浩 氏（日本ヒューレット・パッカード株式会社）
題：「インシデント・マネージメントに関する国際規格化の動向」
情報セキュリティ･インシデント・マネジメントに関する国際規格として、ISO/IEC 18044 Information security incident managementという技術文書がある。この文書は国内であまり知られていないが、ISO/IEC 27001がインシデント・マネジメントの管理策として参照している文書である。現在、これを技術文書から国際標準に改めてISO/IEC 27035として制定する作業の主査を担当しているので、これについて紹介する。審議中の27035は公表できないため、既に発行されている18044から継承される基本的な考え方を紹介する。
18044には、情報セキュリティに関するイベントとインシデントという２つの重要な用語がある。定義は次のとおりである。（邦訳については、JIS Q 27001を参照するとよい。）
Information security event:
An information security event is an identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be security relevant.
Information security incident:
An information security incident is indicated by a single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security.
イベントは事象のことであり、情報セキュリティの侵害の可能性又はセキュリティに関連する未知の状況が見出されることである。
インシデントの定義は、unwanted or unexpectedな事象群と表している。unwantedは組織が望んでいない事象ということである。組織に被害をもたらせば、インシデントとして対応するのは当然のことだ。unexpectedも予期せずに悪いことが起きれば、それはunwantedとほぼ同義である。しかし、unexpectedにはもう一面ある。それは結果が悪いことではない場合である。
たとえば、原因となる何かが発生したとき、それに対する対策を何も講じていなかったため、本来は被害が出ても当然なのに、なぜか、被害には至らなかったという場合である。その場合にも、たまたま運がよくて被害にならなかったが、インシデントの兆候と捕らえて、対応することを推奨する意味で、unexpectedをあえて追加している。
仮に、結果的に被害がなければインシデントとしないということでは、同じ原因が発生したときに、次は被害になるかもしれない。被害に至らなかった事象に対しても対応をしておけば、同じ原因が将来発生した場合に、被害を未然に防ぎやすくなるはずである。
以上のように用語を定義した上で、以下のことを18044では示唆している。
インシデントへの対応手順や体制を整備することが最初に必要である。しかし、インシデントを迅速に対応できる体制が確立しても、日常的に発生している多くの事象を、現場の当事者がインシデントとして認識するのが遅れると、結果的に対応が遅れてしまう。
消防署が１１９番で連絡を受けてからの対応をいくら迅速にしても、１１９番への通報が遅れれば、結果的に火災発生から消防車の現場到着までの時間を短縮できないようなものだ。
そのようにならないためには、インシデントと認識される以前の事象にも広く注意を払う必要がある。
しかし、これは簡単ではない。なぜなら、現場からあらゆる事象をインシデント対応チームに報告されても困るかもしれないからだ。すべてのことをチームで仕分けるので些細なことでも遠慮なく報告せよとするのか、何らかの基準を示して仕分けてから報告させるかのトレードオフは意外と大変なことである。
先の１１９番通報の喩えで言うならば、煙を見たらすぐ通報するのか、それが火災かを煙の元まで行って確認するなどしてから通報するのかの違いということになる。
18044では、これについてはガイドするには至っていない。27035では、類型化についてのガイドを加えることを試みる予定だが、まだ具体的な審議には至っていないので、今後の動向をご確認いただきたい。
いずれにせよ、インシデントとなる可能性や未知の状況を示している事象が、情報セキュリティを脅かす確率が高くなることでインシデントに変遷するという考え方をすることが重要である。このとき、事象そのものが変化するわけではなく、組織としてのその事象の捉え方が変わるだけであるという点に注意が必要である。煙という事象が、焚き火によるものなら単なる事象であり、火災によるものならばインシデントになるということである。
見え方が変わるのではなく、見方を変える必要があるということだ。
18044が示唆していることで特徴的なことは、もう１つある。
インシデント対応は、事前計画に基づく対応手順を充実させて、インシデント発生時に対応することが基本である。しかし、その一方で、事前に用意した手順がインシデントの実情に沿わないときには、手順以外の方法による対応をするための手続きが必要である。なぜなら、事前に想定した範囲だけで実施することは、むしろ想定外の状況に柔軟に対応をできなくなるからだ。そのため、想定外の状況に遭遇した場合に、実際の担当者の判断で、例外処置をできるようにすることが必要となる。
例外処置というと、希少のように思うかもしれないが、実は意外にそうでもない。事前計画に基づく対応手順とは、何らかのインシデントを想定して用意することになる。その場合には、そもそも想定したインシデントの原因については予防対策をするのが自然だ。そのため、むしろインシデントになるものは、想定外のことである割合は多いと考えて、例外が発生した場合の手続きを整備することが重要となる。
それが明確でないと、担当者がよかれと思って対処したことが、後になって標準手順違反として処分されるかもしれない。それでは、担当者は、標準手順の遵守と、自身の責任問題との究極の選択が迫られてしまう。そのとき、誰もが自分の責任問題を二の次として皆にとって最善の対処をするとは限らない。誰もがビバリーヒルズコップのエディ・マーフィやダイハードのブルース・ウイルスではない。
例外処置を容認すると収拾がつかなくなるのではないかと思われるかもしれないが、想定外のことが起きても安全性を維持することが求められるＨＲＯ（高信頼性組織）では、事象をインシデントの兆候として注意深く確認するとともに、標準手順以外の選択肢がないかの思考を絶やさない姿勢をマインドフルと呼んで、高く評価している。
例外処置をいささか強調したが、想定範囲内であれば、標準手順を軽んじることがあってはならないのは当然である。
想定外のことが発生するということを想定するのは、自然なことでありインシデント・マネジメントにおいて大切なことなのである。
27035では、インシデントの類型化のガイドを試みようとしているが、その他に、インシデント・マネジメントそのものの改善をどのように評価するのかについても今後検討していく必要がある。
現時点で言えることは、インシデントの発生回数は、情報セキュリティ対策の評価指標となり得るが、インシデント・マネジメントの評価指標ではない。まだ、国際規格としての議論は進んでいないが、事象を社内の誰かが発見してから、インシデント対応に着手するまでの時間などは、インシデント・マネジメントの評価指標になり得るものと考えられる。そのように測定可能な時間であれば、それを短縮するという改善計画を作成することができる。その他にも評価指標についての検討を継続していく必要があるものと考えている。
