10月1～4日に、米国フロリダ州オーランドでSplunkのプライベートイベント「Splunk .conf 18」が開催された。セキュリティ製品を担当するOliver Friedrichs氏に、同社のセキュリティ戦略について聞いた。
なお、日本法人Splunk Services Japanでセールスエンジニアリング本部長を務める三船亜由美氏によると、日本ではSplunkをセキュリティ用途で使っているユーザーが多いという。もともとSplunkは、IT運用の分野での活用からスタートしたが、新たな用途としてセキュリティ分野の開拓が進んだタイミングがちょうど日本進出の時期と合致したことも一因となり、セキュリティ分野での活用に注目が高まったのだろうと話す。そのため、米国ユーザーの主な用途はIT運用で、セキュリティがそれに続くという比率に対し、日本のユーザーの大半がセキュリティ用途という、米国とは異なる状況になっている。
既存セキュリティ製品とSplunkのセキュリティ機能との違い
Splunk Security Automation and Orchestration担当バイスプレジデントのOliver Friedrichs氏。Splunkが買収したPhantomの創業者で最高経営責任者（CEO）を務めていた
Splunkで実現するITセキュリティは、ログデータなどの分析から通常とは異なる挙動などを発見するというアプローチだ。既存のセキュリティ製品との比較では、一般的なEDR（Endpoint Detection and Response：エンドポイントでの検出と対応）やSIEM（Security Information and Event Management：セキュリティイベント／情報管理）と類似のアプローチといえるだろう。
EDRとの違いは、Splunkのプラットフォームがデータにフォーカスしているものの、一般的なEDRはファイルやエンドポイントにフォーカスしている点だ。Splunkでは、EDRを含む膨大なシステムからデータを収集し、分析することが可能なので、EDRよりもむしろSIEMと比較すべきだろう。Splunkプラットフォームでは、特定のセキュリティ製品などに限定されず、企業全体のさまざまなデータを対象とできる点が強みとなる。
Friedrichs氏によれば、Splunkプラットフォームでは、データを収集し、“答え”をデータから見つけ出すことができる。大量のデータから迅速に答えを得られるため、より正確な解を引き出せる点がSplunkの優位点だとする。
データを解析して状況を理解するという作業は、企業内のセキュリティ担当者がSOC（Security Operation Center）において日常的に行っていることだ。より大量のデータ、より広範な対象システムからのデータを集めることで、広範な脅威を見つけ出すことができるようになる。とはいえ、Splunkプラットフォームの機能は基本的にはデータの収集と分析を支援することにあり、例えばSOCがセキュリティ脅威を発見した後で実行する“アクション”のところは、別のシステムに任せることになる。
この点で同社は、4月に買収合意を発表したPhantomによって、脅威発見後のアクションの部分をPhantomに任せることができるようになるとする。つまり、この買収によってSplunkのソリューションでは、脅威の発見から対応までをカバーできるようになった。あらかじめ設定された“プレイブック”に従い、必要な対応を自動的に実行できる。SOCの担当者は対応作業から解放されることができるようになるため、彼らは新たな脅威の発見に注力することができるようになるという。
Splunkプラットフォームを導入している企業の多くは、セキュリティベンダーが提供するさまざまなセキュリティ製品も既に導入している。SymantecやMcAfee、IBMなど、おおよそ一社当たり60種程度の製品が導入されているという調査結果もあり、Splunkプラットフォームを活用して、これらの既存製品からのデータを収集し、SOCの担当者が適切な調査を行うことで、より高いレベルでの脅威の発見が可能になるだろう。
自動化のためのプレイブックは、Phantom製品に含める形でまずはSplunkから50種をサンプルとして提供するが、これをベースにユーザーがそれぞれ独自のプレイブックを作成できるという。Phantomには、グラフィカルな形でプレイブックの編集ができる「Playbook Editor」機能が付属し、ユーザーは、ドラッグ＆ドロップの分りやすい操作でプレイブックを編集できるとのことだ。
Friedrichs氏によると、あるユーザー企業の実例では、既に80種もの独自のプレイブックを本番環境で運用しており、四半期ごとに14万ほどのセキュリティイベントを処理するうち、約3000件を除く13万7000件の自動処理が可能になっているという。残る3000件は担当者が処理すべき案件としてキューに入れられるが、結果として90％以上のセキュリティイベントが自動処理可能となったことで担当者の生産性は大幅に向上し、自動化できない重要かつ難しいイベントの処理に十分な時間を割くことが可能になった。
