「名ばかりのCSIRT」を作らないために必要なこと：セキュリティインシデント対応のキモは「情報共有」にあり

サイバー攻撃の増加を背景に、防御一辺倒ではなく、「侵入は起こり得る」という前提に立ってCSIRTの構築と運用に取り組む企業が増えてきた。せっかく整備する以上はうまく運用し、迅速かつ適切なインシデントマネジメントを実現したいものだ。そこに欠かせない要素とは何か。エキスパートに話を聞いた。

[PR／＠IT]

国内で広がるCSIRT設置の機運

　あらためて強調するまでもなく、企業を取り巻くサイバー脅威は増加の一途をたどっている。大規模な情報漏えいにつながる恐れのある標的型攻撃や、業務に不可欠なファイルを暗号化するランサムウェア、Webサイトの脆弱性を突いた改ざんなど、さまざまなセキュリティインシデントがメディアを騒がせている。多くの企業がウイルス対策ソフトの導入やファイアウォール、IDS（Intrusion Detection System：侵入検知システム）/IPS（Intrusion Protection System：侵入防止ステム）といった何らかの対策をとっているにもかかわらずだ。

　こうした状況を踏まえ、これまでのセキュリティ対策の在り方を見直す動きが広がっている。具体的には、防御は重要だが、「それでも侵入は起こり得る」という前提に立った取り組みに注目が集まり始めているのだ。

　そこで中核的な役割を果たすのが、組織内CSIRT（Computer Security Incident Response Team）である。セキュリティ情報に目を配り、検知サービスや監査を活用して防御を固め、事故発生時のワークフローを整備するといった事前対応と同時に、従業員の教育／トレーニングを通じてセキュリティ品質の向上に取り組む。そして、万が一事故が発生すれば、第一報を受けて状況を整理し、優先順位を付け、社内外とコミュニケーションを取りながら迅速に対応を進め、被害の最小化に取り組むチームだ。

CSIRTが行うセキュリティインシデント対応のスキーム

　国内では、CSIRTの構築に取り組む企業が大手を中心に増加している。例えば日本情報システム・ユーザー協会（JUAS）が2017年2月に公表した「企業IT動向2017」の速報によると、回答企業の約1割がCSIRTを設置済みと回答している。日本シーサート協議会（NCA）への参加チームも急増しており、2016年の1年間だけで約90チームが新たに加わった。この流れは、より規模の小さな企業へも広がり始めている。

「名ばかりのCSIRT」に陥らないポイントは、インシデント情報の共有

　ただ、いざCSIRT構築プロジェクトを始めてみると、企業が直面する課題は幾つかある。1つは、言うまでもないがセキュリティ人材不足。もう1つは、CSIRT内外で「セキュリティインシデント対応に関する情報をうまく共有する仕組みやワークフローが構築できていない」ことだ。

　2017年現在、CSIRT、あるいはCSIRT的な役割を担う組織の多くは、メールで個々にやりとりをしていたり、Microsoft ExcelやAccessなどでインシデント管理をしていたりするのが現状だ。JPCERTコーディネーションセンター（JPCERT/CC）がNCAと共同で行った「2015年度 CSIRT構築および運用における実態調査」によると、インシデント対応を追跡するためのトラッキングシステムやワークフローを導入しているCSIRTは3割程度にとどまっている（*）。

* 出典：JPCERTコーディネーションセンター「2015年度 CSIRT構築および運用における実態調査」（2016年6月29日公開）

　しかしこういった体制では、情報が必要な人全てに行き渡らなかったり、逆に、多くの人に情報が共有され“過ぎた”結果、誰が責任を持って対処するのかなどの観点が曖昧（あいまい）になったりする。結果として、せっかくアラートが出ても、対処が行われないままになってしまうことがあるという。

ネットブレインズ ソリューション事業部 事業部長の矢木眞也氏

　ヘルプデスクの運用を支援するITサービスマネジメントソフトウェア「ServiceDesk Plus」の販売を行ってきたネットブレインズの矢木眞也氏（ソリューション事業部 事業部長）は、「業務PCが壊れたならば、その人と一対一で『では、明日代替機を送ります』といったメールをやりとりすれば済むでしょう。しかし、“何らかのマルウェアに感染して、増殖傾向にある”といったセキュリティインシデントが発生した場合には、適切な担当者に適切な方法でインシデント発生の報告がなされなければ、組織としての初動対応が遅れてしまいます」と指摘する。

　しかもセキュリティインシデントは、一般的なIT機器やソフトウェアのトラブルとは異なり、対応が社内のみで完結するとは限らない。内容によっては、システムの運用を補佐してもらっているシステムインテグレーターやセキュリティの専門知識を持ったマネージドサービスプロバイダーと連携して対応に当たることが重要であり、その結果、被害が深刻なことが判明したならば、顧客やパートナー企業、場合によっては監督官庁に報告する必要が生じる。そのときに不可欠なのは、「正確な記録」だ。

　「このセキュリティインシデントは、最初にいつ報告され、今どういう状況にあり、誰が誰とどう連携しながら対処したか、といった記録を時系列で的確に残しておくことが大切です。インシデントのステップごとに、『これは誰が確認したのか』『経営層には報告済みなのか』などと、過去のメールや履歴などを検索しながら、いちいち確認しなければ分からないようでは、時間も手間もかかるだけです。いつ、誰がどういった内容でエスカレーションしたかが順番に記録として残り、一目瞭然になっていることが大事です」と矢木氏は指摘する。

　しかし、目の前にあるインシデントへの対応に忙殺されているCSIRTのメンバーに、作業と同時に記録も手作業で行え、というのは無理な注文だろう。セキュリティインシデントに関する情報を少ない手間で共有する、何らかの「仕組み」が必要である。

階層的なエスカレーションや一斉共有も可能な「ManageEngine ServiceDesk Plus」

　こうした課題の解決にぴったりなのが、ゾーホージャパンが提供する「ManageEngine ServiceDesk Plus（以下、ServiceDesk Plus）」だ。ServiceDesk Plusは、もともとはITIL（Information Technology Infrastructure Library：ITサービスマネジメントのベストプラクティスをまとめたフレームワーク）に準拠したITサービスマネジメントのためのツールで、国内外でおよそ10万社もの企業に採用されている。

　実は、ServiceDesk Plusの持つインシデント管理や変更管理、問題管理といった機能は、そのままCSIRTのインシデントハンドリングにも活用できることをご存じだろうか。つまり、組織として対応を進める基盤となる「情報共有プラットフォーム」として活用できるというわけだ。事実、矢木氏によると「この2年ほどで、ServiceDesk PlusをCSIRTにおけるセキュリティインシデント対応管理に活用するケースが増えてきています」という。

ServiceDesk PlusのITサービス管理フロー

　ServiceDesk Plusでは、メールやWebフォームで入力された内容を「リクエスト」と呼ばれる単位で管理する。併せて、サーバやネットワーク監視ツールが出力するログアラートも、リクエストとして記録する仕組みを備えている。CSIRTでも、こうした機能をそのまま応用できるのだ。

　具体的には、ファイアウォールやIDS/IPS、UTM（Unified Threat Management：統合脅威管理）といったセキュリティ機器、あるいは統合ログ解析ツールのSIEM（Security Information and Event Management：セキュリティ情報イベント管理）が出力したアラートやログを受け取り、セキュリティインシデントとして登録できる。そして、あらかじめ設定しておいた業務ルールやポリシーに応じてカテゴリー分けや緊急度、重要度を自動的に適用し、必要な人物に通知したり、承認を求めたりする、一連の流れを統合した体制を容易に構築できる。

　「セキュリティインシデントでは階層的なエスカレーションが必要で、場合によってはトップまでエスカレーションしなければなりません。しかし、そういった場合にメールだけでプロセスを進めるのは困難ですし、それができるとしても時間がかかります。ServiceDesk Plusがあれば、当該インシデントのレポートにエスカレーションのフラグを立てるだけで情報を共有できます。全社的に一気に情報を展開しないと対応が遅れてしまうといったときも、簡単に周知できる仕組みになっています」（矢木氏）。

　セキュリティ人材不足が叫ばれる昨今、自社内でセキュリティインシデントの分析から対応までを完結できる企業は少ない。従って多くの企業では、一時的なアラート対応は自社内で行いつつも、より詳細な分析が必要な場合には外部の企業が提供するマネージドセキュリティサービスやSOC（Security Operation Center）サービスを活用していることだろう。

　ServiceDesk Plusはこうした体制のフローにも柔軟に対応できる。例えば、企業内システムに導入した機器からのアラートはServiceDesk Plusに集約し、必要に応じてSOCサービスを提供しているセキュリティ企業のアナリストにエスカレーションする。そして、分析結果を基にして「ファイアウォールのポリシーをこのように変更しましょう」などといった推奨案を経営層に提示し、経営層側の承認が得られたら変更を実施する。このような一連のプロセスもServiceDesk Plus 1つで全て管理できる。

防御一辺倒から、「フローも含めた事故前提型の対策」へのシフトを

　昨今の脅威の増加によってセキュリティ対策の注目度は上がり、投資も増加傾向にある。しかし、その予算配分には偏りがあるようだ。「UTMやエンドポイントセキュリティといった防御に対する投資は進んでいます。しかし、インシデントを検知した後の対応についての投資は進んでいません」と矢木氏は述べる。

　CSIRTの役割はここを補うことだ。インシデント発生を防止する策を講じつつ、万が一に備え、アラートを受けたならば誰が対応し、分析結果に応じて誰に通知し、判断を仰ぐのかといった対応フローを整備しておく。そして、いざというときにはそれに沿って迅速に対処を進める。ServiceDesk Plusでは、プログラミングを行うことなく簡単に、こうしたフローを実装してインシデント対応を進めることができ、初期対応をスムーズに行える。対応履歴も適切に残されるため、いつ最初のアラートが入り、誰がどのように判断し、どんな対処が必要だと決めたのかといった一連のプロセスを管理し、情報を共有するのも容易だ。

　「アラートが出た“後”の対応を考えておき、“効率的な情報共有の仕組み”を正しく取り入れることによって、あなたの会社のセキュリティ対策レベルは数段階も高まるはずです」（矢木氏）

　これまで、日本のセキュリティは、長らく防御一辺倒で考えられてきた。しかし、それでもセキュリティインシデントはゼロにはならず、それだけを過信していると、むしろ重大な事案にまで発展してしまう恐れがあることが明らかになっている。だからこそ、「セキュリティインシデントに備え、情報をどう共有し、どう対応するか」という“その後”の部分に備えることが重要なのだ。そうすることで、企業のセキュリティ対策レベルは上がり、CSIRTを有効に活用できるのではないだろうか。そのときにServiceDesk Plusは大きな力になるだろう。