はじめに
セキュリティについては、前回脆弱性についての講義を受けて三回に分けて投稿した。今回はそのセキュリティについてもう少し踏み込んで考えてみた。
ITの光と陰
企業活動にとってITの利用は必須だ。ITを利用することで企業の競争力を高めることもできるが、一方的でトラブルに遭遇することもある。後者のことは最近はインシデントと呼ぶことが多い。
ITIL
インシデント管理を調べるとITILで定めるサービスサポートの中の概念だった。ITILとは、Information Technology Infrastructure Libraryの略で、欧米ではITサービスマネジメントの業界標準として広く認知されているが、国内ではまだまだ知られていない。少し説明すると、ITILでは3つのPという概念を重視している。3つのPとは、プロセス(process)、人(people)そして、成果物(products)だ。プロセスだけでもダメ、IT担当のスキルだけでもダメ、この３つのPがバランス良く配置されることが重要だと説いている。最近では、協力会社(partners)を含めた4つのPということもある。
サービスサポート
ITILのサービスサポートは下の表に示すように、5つのプロセスと1つの機能(サービスデスク)で構成する。
出典：ITIL
インシデント管理
今回のメインテーマであるインシデント管理がやっと出てきた。ITILの定義によればインシデント管理とは、解決プロセス群の一つだ。インシデントとは、提供するサービスの中断(事故)を意味する。インシデント管理とは、発生したインシデントに対して対策し、解決するまでの一連の流れを管理することだ。なお、インシデント管理はあくまで暫定対応までを対象としており、根本的な恒久対策は問題管理プロセスの対象だ。このあたりの考え方はITILとして非常によく整理されている。インシデント管理の目的はあくまで業務復旧だ。下の図はこの流れをうまくまとめている。
出典：senju family
CSIRT
CSIRT(Computer Security Incident Response Team)については、この前のブログでも少し説明したが、最近は企業内にCSIRTを設置する会社が増えている。それだけITのインシデントが増えているということだ。社員の不注意で発生するインシデントもあれば、悪意のある外部からのサイバー攻撃を受けることもある。これまではファイアーウォールを設置して、入口管理を強化することが求められていたが、現在はもうそれだけでは不十分だ。常にインシデントを管理し、発生したインシデントにいち早く適切な対応をすることが求められている。CSIRTの役割としては次の３つがある。
1) 社内対応：セキュリティ情報の提供や指示・命令系統の整備・管理
2) 社外対応：社外からの問い合わせやインシデント情報についての統一した対外窓口
3) 情報連携：外部のセキュリティ組織や他社のCSIRTと連携し、セキュリティに関する情報を共有
CSIRTの３つのタイプ
NRIの調査によると、社内CSIRTの形態は自社完結型と一部委託型と複合型に分類できるという。そして、自社完結型が43.8％、一部委託型が27.1％、複合型が22.9％だという。
・自社完結型は、CSIRT機能のほぼ全てを自社内に持つ体制で、金融やIT業界に多いという。
・一部委託型は、CSIRT機能の多く自社内に持ちつつ部分的な機能を外部に委託する体制だ。
・複合型は持ち株会社が情報連携のハブ役を担いつつ各種対応をグループ内の情報システム会社が担う体制だ。
少し残念なのは、同じくNRIの調査によるとCSIRTを構築済みなのはわずか7.3%であり、そのうちCSIRT活動が予算化され十分な活動ができているのは27%だという。つまり、調査したうちのわずか2%のみが十分な活動ができていて、残り98%はまだまだだ(涙)。
出典：NRI
CSIRTの責任者＝CISO
CEOとかCIOとかCTOなら聞いたことはあっても、CISOを知っている人は少ないのではないだろうか。CEOとはchief executive officerの略で経営最高責任者だ。CTOはchief technical officerの略で、最高技術責任者だ。IT系の企業にはCTOを任命している企業が多い。CIOは最高情報責任者でchief information officerの略だ。そして、CISOとはChief information security officerの略で、最高情報セキュリティ責任者だ。CISOは、CIOとセキュリティ責任者を合わせたものだ。下の図はCISOの位置付けをわかりやすく描いている。IIJの資料なので、右上にIIJのアドバイザーがついている。
出典：IIJ資料
知らぬが仏
社内でどれだけのインシデントが起きているのかを理解していないのが現状かもしれない。知らぬが仏とは良く言ったものだ。知らなければ余計な仕事をしなくても済む。しかし、軽微なインシデントはそれでも良いのかもしれないが、重大なインシデントが発生して、経営が行き詰まるような事態になるのは避けなければならない。そのためには、やはりインシデントの見える化がとても重要だ。インシデント管理の最初はやはり下の図のようにインシデントの可視化が重要だ。
出典：日経BP
インシデントの種類の整理
インシデントを分類すると、下の図のように、サイバー攻撃と事故がある。サイバー攻撃には標的型攻撃的やマルウェア感染、不正アクセスなどがあり、事故には盗難・紛失、誤送信、情報漏洩などがある。インシデントは本当に日常的に発生しているという認識が重要だ。この辺りはヒヤリハットの法則が通じそうな感じがする。
出典：NEC
まとめ
パソコンをなくしたり、USBをなくしたり、メールの誤送信をしたりといった事故が発生するたびに社内では原因と対策が議論されて、社内の情報システムはどんどん厳しくなる。まあそれはそれでやむをえないが、情報機器の利用方法を制限して、ファイアーウォールを厳しくしてもインシデントはなくならない。これはまるで、頭髪の色を決め、スカートの長さを決め、爪の長さを決めるなど校則を厳しくしても生徒のいじめやトラブルは無くならないのと構図が良く似ている。大切なことは見守ることだ。傍観者というと、マイナスのイメージがあるが、傍で良く観てあげて、できれば声をかけてあげれば悲惨な事故は防止できるのではないかと感じることが多い。サイバーの世界のインシデントも同じだ。インシデントが発生したことを責めるのではなく、この程度のインシデントで治ってラッキーだったというぐらいの謙虚な姿勢が必要だ。そして、インシデントを解決する＝暫定対処で終わるのではなくて、その元原因を究明して、抜本的な対策＝問題管理を行うことでインシデントを減らすのが本道だと思う。技術士の試験では、このインシデント管理とか、CSIRTに必要性を問う問題は出そうな気がする。まあ、その時には余計なことは書かないようにして、必要なことだけを分かりやすく回答しましょう。
以上
最後まで読んで頂いてありがとうございました。
拝
