このページの本文へ

インシデント対応は45%短縮、共通プラットフォームと自動化がセキュリティ担当者にもたらす価値

ServiceNowが脆弱性対応日数を60%短縮できる理由、担当幹部に聞く

2018年09月14日 07時00分更新

文● 末岡洋子 編集● 大塚/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 ServiceNowでは、もともとITサービスマネジメント(ITSM)の機能をSaaSとして提供するために構築したクラウドプラットフォームを転用して、企業内のさまざまなサービス業務におけるワークフローの効率化を推し進めてきた。

 そのServiceNowが2年前に進出したのが「セキュリティオペレーションマネジメント」の分野だ。企業のセキュリティチームとITチームが共同作業を進められる単一のプラットフォームを提供することで、インシデント対応や脆弱性対応といったセキュリティオペレーションの迅速化、効率化が実現するという。

 今回はServiceNowでセキュリティ&リスク担当シニアディレクターを務めるピエロ・デパオリ氏に、セキュリティオペレーションマネジメント分野におけるServiceNowの価値、今後の取り組みなどを聞いた。

ServiceNow セキュリティ&リスク担当シニアディレクターのピエロ・デパオリ(Piero DePaoli)氏

――まず、ServiceNowがセキュリティオペレーションマネジメント領域に進出した理由について聞かせてください。何を解決しようと考えたのですか。

デパオリ氏:ServiceNowでは、2016年2月の「Geneva」リリースからセキュリティオペレーションマネジメントのサービスを提供開始し、その後も継続的に機能を強化してきました。このサービスを開発した理由は、企業におけるセキュリティインシデント対応業務を改善する必要があると感じたからです。

 現在の企業はすでに多額のセキュリティ投資を行っています。大企業になると数十種類ものセキュリティ製品を導入しており、セキュリティチームは毎日毎日、こうした製品から多数のアラートを受け取ることになります。アラートを受け取ったら、次のステップは迅速にインシデントの優先順位付けをし、対応と管理を進めていくことです。

 しかし、現実にはアラートの数が増えすぎて、どれからフォーカスすればよいのかわからなくなってきます。困ったセキュリティチームは、手作業でコンソールからスプレッドシートにアラートを書き出し、そのリストを使ってなんとかインシデント管理をしようと考えます。しかし、こうした手作業によるプロセスでは時間がかかってしまい、一刻を争うセキュリティインシデントへの対応としては不十分です。また、インシデント対応にはITチームの協力も必要ですが、メールベースで連絡するならば時間も手間もかかります。

 現代のセキュリティ対策は、アンチウイルスやファイアウォールなどを使った「防御(Protect)」だけでなく、防御レイヤーが見逃してしまったものも含めて脅威を発見する「検知(Detect)」、そして検知した脅威をいち早く封じ込め、被害の発生や拡大を防ぐ「対応(Response)」という3つの要素が必要とされています。ServiceNowのクラウドサービスは、顧客企業がこの「対応」業務を迅速に行えるよう支援します。

 ServiceNowがITSM分野のクラウドサービスからスタートしたことはご存知だと思いますが、そのコアとなる考え方は「これまで手作業でまかなわれてきたプロセスを構造化し、自動化できるものは自動化して業務効率を向上させる」というものであり、これをセキュリティインシデント管理/対応業務に応用したわけです。

 この市場はまだ新しい分野で、呼び方もさまざまです。ガートナーは昨年末に「セキュリティ・オーケストレーション・オートメーション・レスポンス(SOAR)」市場と定義しましたし、フォレスターでは「セキュリティ・オートメーション・オーケストレーション」と呼んでいるようです。

――ServiceNowが提供するセキュリティオペレーションマネジメントの機能は、具体的にどのようなものですか。

デパオリ氏:Genevaリリースで最初に投入したのは、「セキュリティインシデント対応マネジメント」「脆弱性対応マネジメント」の2種類です。

ServiceNowが提供するセキュリティオペレーションマネジメント機能の概要(2016年の説明会資料より)

 セキュリティインシデント対応マネジメントでは、シマンテックやパロアルトネットワークスなどのファイアウォール製品、エンドポイントセキュリティ製品、SIEM製品など、幅広いセキュリティツールからのアラートや情報をAPI経由で統合し、ServiceNowで一元管理できます。ServiceNow上で新たなインシデントが作成されたら、セキュリティチームの担当者がワークフローを設定し、対応作業を進めます。たとえば、マルウェア感染、DDoS攻撃、フィッシング詐欺など、誰がどのように対応作業を行うのかのタスクを決めることで、適切な担当者に適切な情報が伝えられ、対応作業が効率的かつ迅速に進みます。

 “受け身”型のインシデント対応とは対極的に、先回りしてインシデントの発生を抑止しようというのが脆弱性対応マネジメントです。Rapid 7など3社の脆弱性スキャン技術企業と提携し、提供された脆弱性情報をServiceNowの構成管理データベース(CMDB)と照合します。CMDBは、社内のサーバーやPCにどんなソフトウェアのどのバージョンがインストールされているかをトラッキングしていますから、脆弱性のあるソフトウェアが発見されたら、パッチ適用などのワークフローを実行するわけです。

 Genevaリリース以後も機能強化は続いています。特に、2016年6月には脅威インテリジェンス企業のBrightPoint Securityを買収して、脅威に関する詳細な情報を取得できるようになりました。これにより、インシデント対応作業がさらに効率化されています。

――セキュリティレスポンスマネジメントにServiceNowのサービスを利用するメリットは何でしょうか。

デパオリ氏:新たに発生したインシデント、発見された脆弱性への対応が、非常にスピーディなものになります。脆弱性対応の場合、それに要する時間が平均で50~60%も短縮できます。インシデント対応のほうも、平均で45%の時間短縮になるという結果が出ています。

 ServiceNowで時間が短縮できる理由ですが、これまでの手作業プロセスを「自動化できるものは自動化する」こと、そしてセキュリティチームとITチームが同じプラットフォームを使ってすべての情報を共有することにあります。たとえば、ITチームが管理するCMDBをセキュリティチームからも参照できるからこそ、セキュリティチームが入手した脆弱性情報やCVSS(共通脆弱性評価)スコアとの照合が可能になり、脆弱性/インシデントの緊急度に応じて自動的に優先順位付けができるようになるわけです。

 別の例も考えてみましょう。セキュリティチームがマルウェア感染した端末を発見し、Active Directoryの設定を変更して当該ユーザーのアクセスを一時的に制限したいとします。しかし、これはITチーム側の作業であり、セキュリティチームでは作業できません。ServiceNowならば同じプラットフォーム上で作業しているので、セキュリティ担当者はすぐにそのタスクをITチームに引き継ぐことができます。「現在はどういう状況でどんな作業が必要なのか」といったことをいちいちメールにまとめる必要もありません。ITチームが必要な情報はすべてプラットフォーム上にありますから。

――脆弱性へのパッチ適用は新しい課題ではありません。WannaCryなどの大きな事件が起きても、なかなか脆弱性管理が進まない理由はどこにあると考えますか。

デパオリ氏:セキュリティ担当者にとって、パッチ当ての作業が“退屈”だからでしょう。だからこそ、ServiceNowでもっと効率化、自動化すべきなのです。

 セキュリティにまつわる問題は「数」と「深刻さ」の両面で悪化し続けています。その一方でセキュリティ人材は不足しており、セキュリティ対策の効率化はどの企業にとっても重要な課題です。たとえすでに脆弱性対応ができている企業であっても、ServiceNowを導入することで、セキュリティ人材を退屈なパッチ適用の作業ではなく、よりエキサイティングな業務へと解放できます。

 当社がポネモンインスティテュートと行った脆弱性対応に関する調査では、企業がパッチ適用に要する日数も調べました。日本企業は、深刻度の高い脆弱性へのパッチ適用に平均13.45日、また深刻度が中/低のパッチには135.94日も要していることがわかりました。前者は世界平均より4日早いのですが、後者は10日も遅い。改善の余地はあります。

――今後の取り組みについて教えてください。

デパオリ氏:次期リリースでは新しいUIを導入し、セキュリティインシデント対応の作業効率をさらに高めます。また、現在すでに40ほどの外部セキュリティ製品と連携することができますが、今後も継続的にその数を増やしていきます。

 これと並行して、セキュリティ対応のプレイブック(シナリオ)作成も進めていく計画です。具体的な対応内容は企業により異なりますので、ワークフローやオーケストレーションなどを自社に合わせてカスタマイズできるようにします。

訂正とお詫び:掲載当初、デパオリ氏の氏名および肩書きに誤りがありました。お詫びのうえ訂正させていただきます。(2018年9月14日)

■関連サイト

カテゴリートップへ