はじめに
脅威管理の世界では、IPS や EDR、SIEM などの検知ソリューションが活躍します。脅威を可視化できなければ、確認も対応/修正もできません。そのため、検知にはセキュリティー関係者の注目が集まります。
しかし、実際に脅威検知ソリューションを運用していく中では、検知した後も重要です。攻撃対象に役員が使用するパソコンや機密データが関わっていたかどうかや、対象システムのメンテナンス・レベルなどの要素で、対応の流れも変わってきます。
しかも、検知アラートには情報の一部しか含まれていないことも多いため、情報の補完や強化が必要になりますし、判断の結果として、実機環境に対して隔離・閉塞などのアクションを起こしたい場合もあります。
一方で、検知対象システムや検知ツールも多岐にわたり、ログやアセット情報などが蓄積する場所も分散しています。ハイブリッド・マルチクラウドの普及によりセキュリティー・データの分散は広域化しており、SIEM のように単一箇所に集約 & 保管して分析することは、常に実現可能とは限りません。
このような理由によって、脅威管理の世界は「SIEMだけで回せない」状況が顕在化してきています。
トップに戻る
SOARの必要性と価値
脅威の管理では、どのように脅威を検知し、それにどう対応するかが重要です。
これは、検知、確認、修正の3つの段階に分けて考えると、理解しやすくなります。
まず、大量にある情報の中から問題を「検知」します。検知では、セキュリティー・ログの収集、正規化、相関、アラートを行います。この機能がSIEMです。➊
IBM の QRadar SIEM は、検知に必要な機能を備えています。
次に、検知されたアラートが、対応を必要とする実際の脅威であるのかを「確認」します。➋
ブラウザーのタブを10個も20個も開きながら、インターネット検索で見つかった情報をスプレッドシートに転記していく…そのような手動の作業を成熟した方法に変えていく必要があります。
インシデント発生後の取り組みが「修正」です。修正のステップでは、検知後いかに素早く対応し復旧できるかが鍵になります。
SIEM、EDR、その他の検知ツールだけでなく、インシデントは Eメールなどからも通知されます。➌
多くのSOCで「人」の不足も課題であり、SOCチームが対処しなければならない脅威も増加しています。
これらの課題に対処するための一連のテクノロジーを、SOAR (Security Orchestration, Automation and Response) と呼んでいます。
SOARにアラートを集約し、ケース管理することで、全員が同じページを見ながら効率的にコラボレーションできるようにし、プロセスに従うことで進行状況を簡単に文書化できるようにします。➍
ダイナミック・プレイブックによってインシデントに応じた必要なタスク・リストを動的に生成し、適切なインシデント対応計画の実行を支援します。➎
また、さまざまな脅威インテリジェンスをSOARプラットフォームに接続して、アナリストのために情報を集めておくことができます。➏
アナリストは情報収集に時間を費やす代わりに、分析結果の解釈と意思決定に集中できます。
検知アラートには情報の一部しか含まれていないことも多いため、情報の補完や強化が必要になります。パソコンの使用ユーザーやサーバーの管理者、ユーザーの所属組織、役職、機密データの有無や導入ソフトウェアのパッチレベルなどの情報は、インシデント対応手順の中でアラート情報に紐付けなければ、判断材料にすることが困難です。
CMDB や LDAP を検索するだけではなく、その場でエンドポイントから最新の情報を採取したい場合もあるかもしれません。
判断の結果として、ファイアウォールやエンドポイントに対して、隔離・閉塞などのアクションを起こしたい場合もあります。
プロセスをオーケストレーションすることで、さまざまなツールとSOARプラットフォームをリンクできます。アナリストにとってツールの複雑さが軽減され、各ツールの詳細を知らなくても、情報収集やアクションなどのさまざまなタスクを完了することができます。➐
さらに、繰り返し行う同じ作業は自動化することで、より短時間かつ一貫性のある方法で、インシデントに対応できるようになります。➑
これらすべての組み合わせにより、SOAR は近代的なセキュリティー運用のハブになります。これにより、インシデントへのより迅速な対応が可能になり、アナリストの生産性と効率が向上します。
IBMはこれらの機能を、QRadar SOAR (Resilient) プラットフォームによって提供しています。
SOARプラットフォームの使用を開始すると、貴重な評価指標が生成され、人・プロセス・技術にまたがって組織の効率を向上させることができます。これは、日々の運用の改善だけでなく、セキュリティー運用のトランスフォーメーションを推進します。➒
このように、脅威の管理では、どのように脅威を「検知」するかだけではなく、それを効率的に「確認」して「修正」することが重要です。
トップに戻る
ハイブリッド・マルチクラウド時代の新しい課題
セキュリティー・イベントの中からSIEMが問題を検知すると、そのアラートが本当の脅威であるのかをアナリストが確認します。➊
セキュリティー・ツールは1つではなく、データレイクやEDRが使われていたり、目的別に複数のSIEMがあることもあります。➋
ビジネスでは、新たな領域への投資が常に行われています。ハイブリッド・クラウドの流れもその1つです。➌
これらは、サイバーセキュリティーの新たな監視対象になります。
監視対象が増えれば、アラート発生時に確認を行うべき調査対象も増えることになります。➍
異なるユーザー・インターフェース、異なるクエリー文法を持つ様々なツールのスキルが求められることは、アナリストの人材確保をさらに難しくします。
また、複数のツールを運用すると、調査に必要な時間が増え、コスト増の要因にもなりえます。
かといって、ビジネスの拡大ペースに合わせて、全てのセキュリティー・イベントを単一のSIEMやデータレイクに集約することは、コストの面で必ずしも有利とは限りません。➎
クラウドから外部へのログ転送には、追加のコストがかかる場合もあります。
これらの課題を解決するためには、(1) 分散した監視対象から届くアラートの一元管理と、(2) ハイブリッド・マルチクラウド環境全体に分散したセキュリティー・データの一括調査 の2つを実現する必要があります。
トップに戻る
SIEM集約とSOAR集約
もともと SIEMは、ファイアウォールやOSなどのシンプルなログにインテリジェンスを提供すると同時に、独自の脅威検知メカニズムを備えたインテリジェントなログ・ソースのアラートを集約し、ログ・ソースごとに異なる重大度の調整や相関分析などを提供する総合的なプラットフォームでした。
そのため、複数のログ・ソースから上がってくるアラートの集約ポイントとして機能し、複数のセキュリティー監視製品を統括する位置に置かれてきました。
しかし、いくつかの変化により、このモデルが常に有効とは限らなくなりました。
1つは、ログ・ソースの変化です。
例えば、普及が進んだ EDR の膨大なログは、まるごと SIEM にコピーするにはコストがかかりすぎることがあります。そのため、アラートのみを SIEM と連携し、それ以外のログはログ・ソース側に留めておくケースが見られます。
また、セキュリティー監視システムを自社で運用せずに、外部のマネージド・セキュリティー・サービスに任せてしまうこともあります。その場合、自社の SIEM に監視対象システムのログを統合できるかどうかはサービス提供者に依存し、場合によっては Eメール通知とポータル画面からの確認しかできないこともあります。
もう1つは、ハイブリッド・マルチクラウド環境によるものです。
これも、1つ目のログ・ソースの変化に近い部分がありますが、SIEM ライクな機能があちこちに散在するようになったという意味で、特徴的です。
当初は点のように存在したクラウド環境も、今や企業の中で大きな島となり、さらに大陸のような巨大な存在になりつつあります。クラウド利用もインフラからアプリまで様々であり、一方でオンプレミス環境も引き続き利用されています。
巨大なインフラを提供するクラウド・ベンダーは、同時にログの集約基盤や監視基盤も提供することがありますし、膨大になってしまったログは、外部の SIEM やデータレイクに安価にコピーできるとは限りません。
このように、セキュリティー監視を SIEM 集約によって効率化できるとは限らない状況となってきました。
ここでも、SOAR がアラート集約ポイントとして役割を果たすことができます。
SOAR は単一の SIEM に対しても「確認」や「修正」といった重要な役割を果たすことができますが、マルチSIEM/データレイクのようにアラート源が散在する環境や、マネージド・セキュリティー・サービスのような Eメール通知しかトリガーがないような連携先が現れたことで、その役割が一層重要になります。
SOAR を活用することで、(1) 分散した監視対象から届くアラートの一元管理 を実現することができます。
トップに戻る
仮想データレイクという選択肢
ここまで、SOAR を活用することによって、たとえ管理対象が分散している環境でも、アラートを集約しつつケース管理やオーケストレーションなどの機能を発揮できることを述べました。
もう1つの課題は、ハイブリッド・マルチクラウド環境全体に分散したセキュリティー・データの調査が煩雑であることです。
確かに、SOAR のオーケストレーションを使えば、散在する管理対象から必要なデータを収集することも可能です。
例えば、マネージド・セキュリティー・サービスから Eメールで通知を受けることで自動的にケースを起票し、その通知 Eメールの本文に含まれていた IPアドレスやファイル名などの IOC を自動抽出して、さらに社内にある EDR や SIEM を検索し、その結果をケースに添付することができます。
しかし、脅威ハンティングを進めるにあたっては、幅広い連携対象に対して繰り返し必要なクエリーを行い、その結果をシームレスに繋ぎ合わせて結果を確認することが必要です。ここで「繰り返し行う」検索とは、対象システムの数だけ繰り返すという無駄な作業のことではなく、原因追求を進めていくにあたって、検索をドリルダウンしていくことを指しています。
このような要件に合致するのが、Federated Search です。
Federated Search は、クエリーを STIX Patterning という共通文法で表現すれば、それが STIX-SHIFTER というオープンソースのPythonライブラリーによって対象のネイティブ文法/APIに変換され、STIX Observationsという共通形式の結果を得ることができる機能です。
これにより、連携対象の種類だけ何回もクエリー文をコンパイルする代わりに、一種類の検索構文で様々な対象システム内に蓄積されたセキュリティー・データを一度にサーチし、正規化&マージされた結果を確認することができます。
従来、セキュリティー・データを一気に検索するためには、単一のSIEMやデータレイクのリポジトリーに、ログなどを収集(コピー、転送)するしかありませんでした。Federated Searchは、各対象システムが使用しているストレージにセキュリティー・データを保管したまま、あたかも仮想的に1つのデータレイクであるかのように、ログを一気に検索する機能を提供します。
Federated Search の流れは以下のとおりです。
1. オープンな標準形式(STIX)で、攻撃・侵入の痕跡(IOC)を検索
2. 標準形式の検索が、各セキュリティー製品のネイティブ検索形式に変換される
3. 変換された検索が、すべてのセキュリティー製品に送信される (API呼び出し)
4. 各セキュリティー製品が、検索を実行する
5. ネイティブの検索結果が、各セキュリティー製品から返される
6. 返された結果は、オープンな標準形式(STIXオブジェクト(JSON構造))に変換される
7. 標準形式のSTIXオブジェクトがキャッシュされ、他のサービスで使用される
Federated Searchの機能があれば、(2) ハイブリッド・マルチクラウド環境全体に分散したセキュリティー・データの一括調査 を実現することができます。
例えば、新種のマルウェア情報の痕跡(IOC)を調べたい場合に、データは元の場所に置いたまま、単一画面から単一クエリー文で一気にIOCの検索をかけることができます。
トップに戻る
アラート集約・重複排除・優先順位付け
前述のSOAR集約モデルの説明において、SOAR を活用することで (1) 分散した監視対象から届くアラートの一元管理 を実現することができると書きました。
しかし、実はまだ課題が残っています。
一つは、同一のインシデントについてSIEMやEDRなどがそれぞれアラートを生成した場合に、SOAR上で別々のケースがオープンされてしまうことです。
(スクリプトなどで自動統合機能などを作り込む余地はありますが)
もう一つは、多数のケースがオープンされている場合において、アナリストがケースに対応する際に優先順位を付ける必要があることです。
これを解決するために、SIEMやEDRのアラートを集約してエンリッチし、関連するアラートをグルーピング(重複排除)した上で、優先順位を付けたケースを自動オープンする機能が追加されました。
対応するケースの数自体を削減した上で優先順位付けが行われるため、アナリストの負担を軽減する効果が期待できます。
トップに戻る
ケースの自動分析と対応アクションの推奨
仮想データレイクを使用すれば、 (2) ハイブリッド・マルチクラウド環境全体に分散したセキュリティー・データの一括調査 を行なえます。
しかし、この調査を常にアナリストが手動で行う必要があるとすれば、バラバラに行う必要があった検索を一括して行えるという効率化にとどまります。
そこで、ケースの自動調査機能の登場です。
自動調査を有効化した場合、仮想データレイクに対してルールや脅威インテリジェンスに基づいた検索が自動的に行われ、複数のセキュリティー・データを相関させて、インシデント・タイムライン や MITRE ATT&CKマッピング をアナリストに提示できます。これにより、インシデントに関する根本原因調査を改善できます。
さらに、分析結果に基づいて推奨アクションを提示することもできますので、提示された案をアナリストが確認してSOARのタスクに変換することで、オーケストレーションや自動化につなげることもできます。
アラート集約・重複排除・優先順位付け機能を含む (1) 分散した監視対象から届くアラートの一元管理と、ケースの自動分析と対応アクションの推奨機能を含む (2) ハイブリッド・マルチクラウド環境全体に分散したセキュリティー・データの一括調査 は、QRadar Suite に含まれる Unified Analyst Experience に統合されており、QRadar SIEM や QRadar SOAR の一部として提供されています。
トップに戻る
QRadar Suiteソリューション
IBM Security QRadar Suite は、セキュリティー・アナリストのエクスペリエンスを統一し、インシデント・ライフサイクル全体のスピードを加速させるために設計された脅威の検出 & 対応ソリューションです。
EDR (XDR)、ログ管理、SIEM、SOAR について、共通化されたユーザー・インターフェースと連携されたワークフローを提供します。
トップに戻る
おわりに
脅威管理において、引き続き「検知」は重要な要素です。
IBMも SIEM、SOAR、Unified Analyst Experience において、様々な検知システムとの連携を推進していますし、買収したReaQtaを QRadar EDR として QRadar Suite に統合しています。
しかし、これまで記したように、検知した後の対応/修正も重要であり、脅威管理の世界は「SIEMだけで回せない」状況が顕在化してきました。
SOARとFederated Searchはこのような状況を好転させるための重要なピースであり、XDR や Threat Detection and Incident Response (TDIR) の流れにも沿っています。
ハイブリッド・マルチクラウドは、デジタル・トランスフォメーションの中で必要な変化ですが、同時にセキュリティーの脅威管理をより困難なものにする可能性があります。
SOARによって近代的なセキュリティー運用のハブを構築し、さらにFederated Search によって分散したセキュリティー・データの一元化を実現できれば、ビジネスだけでなくセキュリティーのトランスフォメーションも前進すると考えられます。
トップに戻る
参考文献